[Python-Dev] PyPy 1.7 - widening the sweet spot

Antoine Pitrou solipsis at pitrou.net
Fri Nov 25 18:37:46 CET 2011


On Fri, 25 Nov 2011 12:37:59 -0500
Brett Cannon <brett at python.org> wrote:
> 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

Uh! Any bad news? :/





More information about the Python-Dev mailing list