[Python-Dev] PyPy 1.7 - widening the sweet spot (original) (raw)

Brett Cannon brett at python.org
Fri Nov 25 18:37:59 CET 2011

On Thu, Nov 24, 2011 at 07:46, Nick Coghlan <ncoghlan at gmail.com> wrote:

On Thu, Nov 24, 2011 at 10:20 PM, Maciej Fijalkowski <fijall at gmail.com> wrote: > The problem is not with maintaining the modified directory. The > problem was always things like changing interface between the C > version and the Python version or introduction of new stuff that does > not run on pypy because it relies on refcounting. I don't see how > having a subrepo helps here.

Indeed, the main thing that can help on this front is to get more modules to the same state as heapq, io, datetime (and perhaps a few others that have slipped my mind) where the CPython repo actually contains both C and Python implementations and the test suite exercises both to make sure their interfaces remain suitably consistent (even though, during normal operation, CPython users will only ever hit the C accelerated version). This not only helps other implementations (by keeping a Python version of the module continuously up to date with any semantic changes), but can help people that are porting CPython to new platforms: the C extension modules are far more likely to break in that situation than the pure Python equivalents, and a relatively slow fallback is often going to be better than no fallback at all. (Note that ctypes based pure Python modules aren't particularly useful for this purpose, though - due to the libffi dependency, ctypes is one of the extension modules most likely to break when porting).

And the other reason I plan to see this through before I die is to help distribute the maintenance burden. Why should multiple VMs fix bad assumptions made by CPython in their own siloed repos and then we hope the change gets pushed upstream to CPython when it could be fixed once in a single repo that everyone works off of? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20111125/d6a7f4e2/attachment.html>

More information about the Python-Dev mailing list