WxPython versus Tkinter.

[Terry Reedy]

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