[pypy-dev] Unify lib_pypy by vendoring six

Maciej Fijalkowski fijall at gmail.com
Sat Dec 6 15:01:16 CET 2014


On Fri, Dec 5, 2014 at 9:09 PM, VanL <van.lindberg at gmail.com> wrote:
> Hi Amaury,
>
> On Fri, Dec 5, 2014 at 9:58 AM, Amaury Forgeot d'Arc <amauryfa at gmail.com>
> wrote:
>>
>> lib_pypy is a portion of the stdlib.
>> It contains the modules that CPython implements in C, and that PyPy
>> decided to implement in pure Python.
>>
>> They describe a different version of Python, and have different features.
>> And why would you want to consolidate the code there, and not say in
>> urllib2.py or unicodeobject.py?
>
>
> Two reasons:
> 1. Pypy bears the maintenance burden for the stuff in lib_pypy. Shared code
> means less maintenance. The rest of the stdlib is just copied over, so there
> is no maintenance burden.

The stdlib might be copied over, but there is still quite a bit of
burden with differing C interfaces, semantics, performance etc. Why
did CPython not decide to go that way in the first place btw?

> 2. Most of the APIs (and locations) for the things in lib_pypy *didn't*
> change very much, as opposed to things like urrlib2 where there was a large
> reorganization. This makes it a better candidate for consolidation.
>
> Thanks,
>
> Van

I'm -1 on the idea unless proven otherwise (it does add burden on
people writing stuff for lib_pypy on python2 for example)


More information about the pypy-dev mailing list