[Python-Dev] PyPy 1.7 - widening the sweet spot
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>
> > 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...
More information about the Python-Dev