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

Brett Cannon brett at python.org
Fri Jun 8 20:29:08 CEST 2012


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
 .

The only sane option I can see then is to keep doing what you and PyPy are
doing and keep a copy of the stdlib, but now you all simply share the repo
instead of keeping your own copies and possibly use subrepos to pull it
into your own hg repos.


> > P.S. Do we need a python-implementations mailing list or something for
> > discussing overall VM-related stuff among all VMs instead of always
> bringing
> > this up on python-dev? E.g. I wish I had a place where I could get all
> the
> > VM stakeholders' attention to make sure that importlib as it stands in
> > Python 3.3 will skip trying to import Python bytecode properly (or if the
> > VMs will simply provide their own setup function and that won't be a
> worry).
> > And I would have no problem with keeping it like python-committers in
> terms
> > of closed subscriptions, open archive in order to keep the noise low.
> I think a python-implementations list would be a fantastic idea - I
> sometimes miss multi-implementation discussions in python-dev, or at
> least come in very late.
>

If other people agree then I will get Barry to create it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120608/47f84b91/attachment.html>


More information about the Python-Dev mailing list