[PATCH 00 of 10] PyPy support

[Matt Mackall]

On Fri, 2010-12-03 at 15:51 +0100, Dan Villiom Podlaski Christiansen
wrote:
> On 2 Dec 2010, at 02:15, Matt Mackall wrote:
> 
> > On Wed, 2010-12-01 at 22:34 +0100, Dan Villiom Podlaski Christiansen
> > wrote:
> >> Hi,
> >>
> >> This series fixes most of the test suite failures when running
> >> Mercurial under PyPy 1.4. I've only tested a pure Python build; the C
> >> modules won't compile as PyPy's cpyext interface lacks the
> >> PyFile_GetLine and PyErr_SetFromErrnoWithFilename APIs.
> >
> > A good benchmark would be running verify.
> 
> Currently, PyPy is about twice as slow as CPython in pure builds. I  
> haven't been able to get the C extensions working on my Mac, but  
> according to the PyPy developers, their C extension wrapper isn't  
> terribly fast. One of them looked at mpatch, and described what it  
> does as ‘happy nonsense’. I'll look into that once these patches get in.
> 
> > In the future, you should stick the patches that are uncontroversial
> > first. In this case, that looks like 1, 7, maybe 8, 9, and 10?
> 
> Sorry about that, but thanks for the pointers. I've reordered the  
> patches in my queue.
> 
> > I'd like some explanation of what's going on in 7.
> 
> I first tried closing the file handle, but that didn't work. I later  
> realised that this was because make_file() could return ‘sys.stdout’.  
> Rather than handling it specially in this code, I've added a patch to  
> make make_file() duplicate sys.stdout when returning it, so that it  
> always results in a new, closable file handle.
> 
> > As for the rest, there are numerous places in the Python docs where
> > reference counting is described as the primary memory management  
> > method.
> > In fact, it's the garbage collector, not the reference counter that's
> > described as optional.
> >
> > If the Pypy people think that diverging from CPython in a way that
> > changes semantics so much that we have to audit all our file  
> > handling to
> > be safe/compatible, they're really not aiming at widespread use of  
> > their
> > toy, are they?
> 
> As others said, reference counting isn't part of the Python language,  
> but an implementation detail of CPython.

I should have been more explicit here: I don't particularly care whether
PyPy matches the letter of the law if it doesn't run the existing
programs I've spent years writing.

(Of course, PyPy's failing here is pretty trivial compared to Py3k,
which has me seriously considering looking for a new favorite language.)

-- 
Mathematics is the supreme nostalgia of our time.