[Python-Dev] PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements

[Stefan Behnel]

Nick Coghlan, 19.04.2011 10:57:
> On Tue, Apr 19, 2011 at 3:06 PM, Stefan Behnel wrote:
>> I think this social problem of the PEP can only be solved if the CPython
>> project stops doing the major share of the stdlib maintenance, thus freeing
>> its own developer capacities to focus on CPython related improvements and
>> optimisations, just like the other implementations currently do. I'm not
>> sure we want that at this point.
>
> We've made a start on that aspect by granting CPython access to
> several of the core developers on the other VMs. The idea being that
> they can update the pure Python versions of modules directly rather
> than having to wait for one of us to do it on their behalf.
>
> Of course, as Maciej pointed out, that is currently hindered by the
> fact that the other VMs aren't targeting 3.3 yet, and that's where the
> main CPython development is happening.

A related question is: when other Python VM projects try to port a given C 
module, would they actually invest the time to write a pure Python version 
that may or may not run within acceptable performance bounds for them, or 
would they prefer saving time by writing only a native implementation 
directly for their VM for performance reasons? Maybe both, maybe not. If 
they end up writing a native version after prototyping in Python, is the 
prototype worth including in the shared stdlib, even if its performance is 
completely unacceptable for everyone? Or, if they write a partial module 
and implement another part of it natively, would the incomplete 
implementation qualify as a valid addition to the shared stdlib?

Implementing a 100% compatible and "fast enough" Python version of a module 
is actually a rather time consuming task. I think we are expecting some 
altruism here that is easily sacrificed for time constraints, in any of the 
Python VM projects. CPython is just in the unlucky position of representing 
the status-quo.

Stefan