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

[R. David Murray]

On Fri, 08 Jun 2012 09:39:47 -0700, "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) -- 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 you can write a test that shows a problem with the code, it doesn't
matter if you found in in a different implementation.  As long
as the change conforms to our backward compatibility policy it
can be fixed in 2.7.

And yes, I agree with your understanding that fixing tests (especially
for things like resources not getting cleaned up correctly) is
appreciated for the 2.7 tests.  We should of course verify whether
or not similar changes are needed for Python3.

As for path to get them in...if you have any question about whether or
not the change is appropriate, post a proposed patch to the tracker.

--David