Test alternative Python implementations

[jayvdb]

Needed for https://github.com/bskinn/stdio-mgr/pull/78

More at https://wiki.python.org/moin/PythonImplementations#Working_Implementations

• [x] MicroPython
• [x] PyPy
• ~Jython~ (Py2 only)
• ~IronPython~ (Py3 not @ production)
• [ ] Nuitka?
• [ ] QPython3?
• [ ] Android CrystaX NDK
• [ ] cygwin
• [ ] msys
• [ ] MinGW, which has ~100 patches!
• [ ] conda, on Windows at least (if different)

[bskinn]

Azure has at least Jython and PyPy -- virtualenv runs them. Not sure about IronPython.

[jayvdb]

I'll focus on IronPython then.

[bskinn]

Looks like Jython is still Py2-only?

[jayvdb]

Re https://github.com/bskinn/stdio-mgr/pull/82#issuecomment-529195949

By default, I expect Windows is different for any Python, because it is different on CPython. Any Python implementation attempting to be like CPython will likely need to replicate some of the same differences, though they may choose to not adopt all of them due to incompleteness/small-devbase or unawareness/small-userbase.

I only have limited exposure to platform issues on PyPy via pyflakes dev/CI maintenance. It does have limited stdio tests and I am pretty sure there were Windows specific problems which caused other maintainers to give up and kill the Windows CI of PyPy, mostly pre PyPy 5.0, but I recall getting stuck on one PyPy 5+ Windows specific problem. Most of these problems however were in the backtraces, both the layout (irrelevant for us) and the context of the error messages (which would mean our tests might fail, only due to different expected error strings)

Looks like Jython is still Py2-only?

Ugh, surprisingly yes.

Effort ongoing at https://github.com/jython/jython3 instead of in https://github.com/jythontools , and no py3 effort appearing at https://hg.python.org/ or in commit messages of https://hg.python.org/jython/

https://github.com/jython/jython3/issues/36 and https://stackoverflow.com/questions/2351008/when-will-jython-support-python-3 are the trackers it seems.

More at wiki.python.org/moin/PythonImplementations#Working_Implementations

I ran into https://github.com/jython/jython3/issues/33 about https://github.com/securesystemslab/zippy, which is missing from the above page. py34? Maybe GraalVM only, or JVM with special flag enabled?

https://beeware.org/project/projects/bridges/voc/ looks nice , and https://github.com/beeware/ has a bunch of cool stuff I've been meaning to play with.

The PythonImplementations wiki page should be annotated with py2 vs py3 info

[bskinn]

MicroPython/CircuitPython?

Brython?

[jayvdb]

MicroPython is probably worthwhile.

Python console/IO on JS runtimes is unlikely to be a reasonable use-case IMO.

Nuitka spits out native binaries, and is under very active maintenance - I've been bugging them a bit lately and seeing regular bugfixes. I havent looked closely enough to see if it injects a real python exe; if it doesnt, the C stub for bootstrapping could have slightly different IO initialisation.

[bskinn]

MicroPython may take a lot of work. Just getting pytest installed is non-trivial, and it may not even run after that.

We may have to come up with a way to automatically rewrite the test suite to meet the MP limitations. Or, curate a separate MP test suite (bleh, DRY!).

Though, we may be looking at a significantly curtailed feature set for MicroPython...maybe even just the 1.0 functionality, which wouldn't be that awful, maintenance-wise.

[bskinn]

IronPython3 isn't yet production-ready.

[jayvdb]

QPython3 ? https://github.com/qpython-android/qpython

[bskinn]

Are there enough mobile apps with enough console I/O to make the platform a meaningful target?

[jayvdb]

My only use of QPython(2,3) was teaching Python to kids with a mobile phone and no computer. 100% 'console', albeit wrapped in the QPython IDE. It was reasonably good. But not a high priority.

[bskinn]

Ahhhh, I never even thought about that angle. Though, I should have, because I sometimes use Python through Termux on my phone...it definitely has some quirks.

How would we emulate those? I know there's a service or few where it looks like a VM but you're actually renting time on real mobile devices...might also be some that are pure VMs?...no idea if any of them have free tiers for FOSS, though.

[bskinn]

Hunh. MicroPython types apparently don't implement .mro():

MicroPython v1.11-303-gc8c37ca40 on 2019-09-10; linux version
Use Ctrl-D to exit, Ctrl-E for paste mode
>>> import sys
>>> sys.stdin
<io.TextIOWrapper 0>
>>> sys.stdout
<io.TextIOWrapper 1>
>>> sys.stderr
<io.TextIOWrapper 2>
>>> sys.stderr.__class__.mro()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: type object 'TextIOWrapper' has no attribute 'mro'
>>> sys.stderr.mro()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'TextIOWrapper' object has no attribute 'mro'

[jayvdb]

MicroPython types apparently don't implement .mro():

That probably means they are old-style py2-ish, based on 'type', not subclassing 'object'.

I have a backport of .mro() at https://github.com/jazzband/contextlib2/pull/21

[bskinn]

Ennnh, I don't think so:

>>> str.__bases__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: type object 'str' has no attribute '__bases__'
>>> import io
>>> io.StringIO.__bases__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: type object 'StringIO' has no attribute '__bases__'
>>> io.StringIO.__mro__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: type object 'StringIO' has no attribute '__mro__'
>>> dir(io.StringIO)
['__class__', '__enter__', '__exit__', '__name__', 'close', 'read', 'readinto', 'readline', 'write', 'flush', 'getvalue', 'seek']

I'm currently at a loss for how even to introspect anything about the inheritance hierarchy in MP.

Also: Yikes, the MRO itself is not CPython-compliant.

[jayvdb]

I've added cygwin, msys and MinGW.

I've been doing a lot of Nuitka the last week for a work project - it is very nice. While attempting to cross-compile Python on Linux, using MinGW, I found they have a wildly patch python, and the patches definitely fiddle with these io streams.

The result of this is I'll be able to add Nuitka "standalone" to the CI here soon. I have >200 core packages working, with notable failures at https://github.com/Nuitka/Nuitka/issues/522

I havent investigated yet, but I think conda might also be using a mingw based Python on Windows instead of the MSVC builds.