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

[fwierzbicki at gmail.com]

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