[PATCH 00 of 10] PyPy support

[Georg Brandl]

Am 02.12.2010 02:15, schrieb Matt Mackall:
> 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.
> 
> 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?
> 
> I'd like some explanation of what's going on in 7.
> 
> 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.

As Dirkjan showed, the Python language spec doesn't mandate reference
counting.  The CPython docs of course mention reference counting when
describing CPython; but they should never do so in a way that indicates
that all implementations need to follow that.  If they do, that is a
bug and needs to be fixed.

> 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?

Since the lack of reference counting isn't just present in PyPy, but also
implementations such as Jython and IronPython, I would not accuse PyPy of
breaking things.  It is recommended practice also in CPython to explicitly
close all resources; to make this easier is one of the reasons why the
"with" statement was introduced.

Of course, as an application Mercurial can decide not to support running
on implementations other than CPython without hurting users of alternate
implementations, since almost everyone of them has a CPython interpreter
installed anyway.

Georg