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

Brett Cannon brett at python.org
Fri Jun 8 19:59:08 CEST 2012


On Fri, Jun 8, 2012 at 12:39 PM, fwierzbicki at gmail.com <
fwierzbicki at gmail.com> wrote:

> On Fri, Jun 8, 2012 at 9:22 AM, Jeff Hardy <jdhardy at gmail.com> wrote:
> > On Fri, Jun 8, 2012 at 8:13 AM, Matti Picus <matti.picus at gmail.com>
> wrote:
> >>
> >> The windows port of pypy makes special demands on stdlib, specifically
> that
> >> files are explicitly closed. There are some other minor issues, in
> order to
> >> merge all the changes necessary to get pypy windows up to speed, around
> 10
> >> modules or at  least their tests seem to need to be modified.
> >> I have been doing a bit of work on the stdlib shipped with pypy 1.9
> >> (version 2.7.2 unfortunately) to make it compliant. Assuming there is
> interest,
> >> what would be the best path to get, for instance, a modified version of
> >> mailbox.py with its tests (test_mailbox.py and test_old_mailbox.py)
> backported
> >> to cpython?
> >
> > These fixes would also be useful for IronPython and possibly Jython as
> > well. Unclosed files are probably the biggest set of failures when
> > running CPython's tests on IronPython (along with assuming that
> > sys.platform == 'win32' means Windows). Whether or not they get
> > backported to CPython, it might be worth finding a way to share the
> > 2.7 stdlib between the alternative implementations (changes to 3.x
> > should go into CPython, obviously).
> I think it's supposed to be alright to push changes to CPython's 2.7
> *tests* (like test_mailbox.py) but not other parts of the standard
> library (like mailbox.py)


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.


> -- I'd love to find a way to share the
> modifications from various implementations though -- and in the 3.x
> future hopefully it can all just end up in CPython's Lib.
>

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120608/03bb1d19/attachment-0001.html>


More information about the Python-Dev mailing list