[Python-Dev] backporting stdlib 2.7.x from pypy to cpython (original) (raw)

fwierzbicki at gmail.com fwierzbicki at gmail.com
Fri Jun 8 20:21:39 CEST 2012

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

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.

-Frank

More information about the Python-Dev mailing list