On 6/4/2014 5:14 PM, Paul Sokolovsky 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.
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.
I would call what you are doing a 'Python 3.n subset, with limitations',
where n should be a specific number, which I would urge should be at
least 3, if not 4 ('yield from'). To me, that would mean that every
Micropython program (that does not use a clearly non-Python addon like
inline assembly) would run the same* on CPython 3.n. Conversely, a
Python 3.n program should either run the same* on MicroPython as
CPython, or raise. What most to avoid is giving different* answers.
*'same' does not include timing differences or normal float variations
or bug fixes in MicroPython not in CPython.
As for unicode: I would see ascii-only (very limited codepoints) or bare
utf-8 (limited speed == expanded time) as possibly fitting the
definition above. Just be clear what the limitations are. And accept
that there will be people who do not bother to read the limitations and
then complain when they bang into them.
PS. You do not seem to be aware of how well the current PEP393
implementation works. If you are going to write any more about it, I
suggest you run Tools/Stringbench/stringbench.py for timings.
--
Terry Jan Reedy
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
