65dc960e3b
unix-cpy was originally written to get semantic equivalent with CPython without writing functional tests. When 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 it was less likely to 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: 1. 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 changing the bytecode output to match CPython anymore. 2. uPy and CPy do different optimisations to the bytecode which makes it harder to match. 3. The bytecode tests are not run. They were never part of Travis and are not run locally anymore. 4. The EMIT_CPYTHON option needs a lot of extra source code which adds heaps of noise, especially in compile.c. 5. Now that there is an extensive test suite (which tests functionality) there is no need to match the bytecode. Some very subtle behaviour is tested 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. |
||
|---|---|---|
| .. | ||
| basics | ||
| bench | ||
| cmdline | ||
| extmod | ||
| float | ||
| import | ||
| inlineasm | ||
| io | ||
| micropython | ||
| misc | ||
| pyb | ||
| pybnative | ||
| unicode | ||
| unix | ||
| pyboard.py | ||
| README | ||
| run-bench-tests | ||
| run-tests | ||
| run-tests-exp.py | ||
| run-tests-exp.sh | ||
This directory contains tests for various functionality areas of MicroPython. To run all stable tests, run "run-tests" script in this directory. Note that bytecode tests are not yet stable and should be run separately in "bytecode" subdirectory. When creating new tests, anything that relies on float support should go in the float/ subdirectory. Anything that relies on import x, where x is not a built-in module, should go in the import/ subdirectory.