On 1/26/2011 3:07 PM, Stephen Hansen wrote:
And, more then a few actually
are pushing for the stdlib to be forked off of CPython, and instead end
up shared by all the major Python implementations (CPython, Jython,
PyPy, IronPython, what else?) as a common resource?
This would be a 'split', not a 'fork' (important difference).
There are really two ideas here.
1. As many modules as possible would have a pure Python reference
implementation. Any implementation could use that until it choose to
replace or supplement with a native-language implementation.
For instance, itertools in coded in C for speed, but the docs give
Python (near) equivalents for clarity. A common Python stdlib would have
a Python-coded itertools. CPython would actually run the C-coded
equivalent renamed _itertools.
Maintaining both versions in parallel would be more work, so this could
only happen if other implementors chipped in to help.
Stephen, you are the first I know of to ask whether such a project would
affect addition of new modules. Hard to say.
2. Separate tests that test compliance with the Python specs (for both
language and stdlib) from tests that test implementation-specific
behaviors. The current CPython test suite mixes both together. If
separated, other implementations could (and would) use the Python tests,
and their people would be more willing to help improve the Python tests.
Many stdlib modules are not at 100% coverage and need expansion.
For instance, "1+1 == 2" tests Python behavior, while "a,b=1,1;
id(a)==id(b)" tests a CPython implementation detail. Last I knew, both
types of tests are in the same test file.
Reference count tests, for example, are also CPython-specific.
Both of these ideas will be looked at after the hg migration.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
