Run `.mpy` files from cpython?
It would be great if there was one unified way to write faster python extensions. For various reasons we can't really port cython to micropython, but what aboutproviding some way for cpython to run mpy extensions? #5083 seems very powerful.
Is there any way to do that? Perhaps is would be easier to provide some sort of bridge between micropython and cpython?
RFC: remove unix-cpy
I think it's time to remove the unix-cpy/ "port" and associated tests.
unix-cpy was originally written to get semantic equivalent with CPython without writing functional tests. When I was writing the initial implementation of uPy it was a long way between lexer and functional tests, so the half-way test was to make sure that the bytecode was correct. The idea was that if the uPy bytecode matched CPython 1-1 then uPy would be proper Python if the bytecodes acted correctly. And having matching bytecode meant that I didn't miss some deep subtlety in the Python semantics that would require an architectural change later on.
But that is all history and it no longer makes sense to retain the ability to output CPython bytecode, because:
- It outputs CPython 3.3 compatible bytecode. CPython's bytecode changes from version to version, and seems to have changed quite a bit in 3.5. There's no point in us changing the bytecode output to match CPython anymore.
- uPy and CPy do different optimisations to the bytecode which makes it harder to match.
- The bytecode tests are not run. They were never part of Travis and I don't run them locally anymore.
- The EMIT_CPYTHON option needs a lot of extra source code which adds heaps of noise, especially in compile.c.
- Now that we have an extensive test suite (which tests functionality) there is no need to match the bytecode. We test some very subtle things with the test suite and passing these tests is a much better way to stay Python-language compliant, rather than trying to match CPy bytecode.
If there are no objections then I'll delete!