[PATCH 00 of 10] PyPy support

[Dan Villiom Podlaski Christiansen]

On 3 Dec 2010, at 18:05, Matt Mackall wrote:

> 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.)

I guess the question then is if you're okay with these changes to  
support PyPy? For what it's worth, I suspect PyPy is in the same boat  
as everyone else when it comes to supporting Python 3.x, as its ~500k  
lines of code would make moving to 3.x a major effort.

--

Dan Villiom Podlaski Christiansen
danchr at gmail.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1943 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20101204/e40dab9d/attachment.bin>