[Python-Dev] PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements (original) (raw)

Maciej Fijalkowski fijall at gmail.com
Tue Apr 19 14:26:21 CEST 2011

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

More information about the Python-Dev mailing list