[Python-Dev] Internal representation of strings and Micropython (original) (raw)

Paul Sokolovsky pmiscml at gmail.com
Thu Jun 5 01:11:10 CEST 2014


Hello,

On Wed, 4 Jun 2014 16:12:23 -0600 Eric Snow <ericsnowcurrently at gmail.com> wrote:

On Wed, Jun 4, 2014 at 3:14 PM, Paul Sokolovsky <pmiscml at gmail.com> wrote: > That said, and unlike previous attempts to develop a small Python > implementations (which of course existed), we're striving to be > exactly a Python language implementation, not a Python-like language > implementation. As there's no formal, implementation-independent > language spec, what constitutes a compatible language > implementation is subject to opinions, and we welcome and > appreciate independent review, like this thread did.

Actually, there is a "formal, implementation-independent language spec": https://docs.python.org/3/reference/

Opening that link in browser, pressing Ctrl+F and pasting your quote gives zero hits, so it's not exactly what you claim it to be. It's also pretty far from being formal (unambiguous, covering all choices, etc.) and comprehensive. Also, please point me at "conformance" section.

That said, all of us Pythoneers treat it as the best formal reference available, no news here.

>> Realistically, most Python code that works on Python 3.4 won't work >> on Micropython (for various reasons, not just the string behavior) >> and neither does it need to. > > That's true. However, as was said, we're striving to provide a > compatible implementation, and compatibility claims must be > validated. While we have simple "in-house" testsuite, more serious > compatibility validation requires running a testsuite for reference > implementation (CPython), and that's gradually being approached.

To a large extent the test suite in http://hg.python.org/cpython/file/default/Lib/test effectively validates (full) compliance with the corresponding release (change "default" to the release branch of your choice). With that goal, no small effort has been made to mark implementation-specific tests as such. So uPy could consider using the test suite (and explicitly skip the tests for features that uPy doesn't support).

That's exactly what we do, per the previous paragraph. And we face a lot of questionable tests, just like you say. Shameless plug: if anyone interested to run existing code on MicroPython, please help us with CPython testsuite! ;-)

-eric

-- Best regards, Paul mailto:pmiscml at gmail.com



More information about the Python-Dev mailing list