[Python-Dev] backporting stdlib 2.7.x from pypy to cpython

Xavier Morel python-dev at masklinn.net
Sun Jun 10 09:42:19 CEST 2012


On 2012-06-08, at 20:29 , Brett Cannon wrote:

> On Fri, Jun 8, 2012 at 2:21 PM, fwierzbicki at gmail.com <fwierzbicki at gmail.com
>> wrote:
> 
>> On Fri, Jun 8, 2012 at 10:59 AM, Brett Cannon <brett at python.org> wrote:
>>> R. David already replied to this, but just to reiterate: tests can always
>>> get updated, and code that fixes a bug (and leaving a file open can be
>>> considered a bug) can also go in. It's just stuff like code refactoring,
>>> speed improvements, etc. that can't go into Python 2.7 at this point.
>> Thanks for the clarification!
>> 
>>> If/until the stdlib is made into its own repo, should the various VMs
>>> consider keeping a common Python 2.7 repo that contains nothing but the
>>> stdlib (or at least just modifications to those) so they can modify in
>> ways
>>> that CPython can't accept because of compatibility policy? You could
>> keep it
>>> on hg.python.org (or wherever) and then all push to it. This might also
>> be a
>>> good way to share Python implementations of extension modules for Python
>> 2.7
>>> instead of everyone maintaining there own for the next few years
>> (although I
>>> think those modules should go into the stdlib directly for Python 3 as
>>> well). Basically this could be a test to see if communication and
>>> collaboration will be high enough among the other VMs to bother with
>>> breaking out the actual stdlib into its own repo or if it would just be a
>>> big waste of time.
>> I'd be up for trying this. I don't think it's easy to fork a
>> subdirectory of CPython though - right now I just keep an unchanged
>> copy of the 2.7 LIb in our repo (PyPy does the same, at least the last
>> time I checked).
>> 
> 
> Looks like hg doesn't have support yet:
> http://stackoverflow.com/questions/920355/how-do-i-clone-a-sub-folder-of-a-repository-in-mercurial
> 

Using that would mean commits in the "externalized stdlib" would go into
the Python 2.7 repo, which I assume is *not* desirable.

A better-fitting path of action would be a hg -> hg convert using a
filemap, as the first comment in your link shows. That would create a
full copy (with history replay) of the standard library, in a brand new
repository.

Then *that* could be used by everybody.



More information about the Python-Dev mailing list