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

[Maciej Fijalkowski]

On Tue, Apr 19, 2011 at 12:01 PM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> 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?

At least from our (PyPy's side), we do use pure python versions a lot.
Their performance vary, but sometimes you don't care, you just want
the module to work. Contrary to popular belief, not all code is
performance critical in standard library. We got quite far without
even looking. Later on we usually look there, but for us rewriting it
in RPython most of the time makes no sense, since pure python code
might even behave better than RPython code, especially if there are
loops which get jitted more efficiently if they're in pure python.

>
> 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.

I think 100% compatible with whatever performance is already a lot for
us. We can improve the performance later on. For example we never
touched heapq module and it works just fine as it is.

>
> Stefan
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/fijall%40gmail.com
>