<br><br><div class="gmail_quote">On Fri, Jun 8, 2012 at 12:39 PM, <a href="mailto:fwierzbicki@gmail.com">fwierzbicki@gmail.com</a> <span dir="ltr"><<a href="mailto:fwierzbicki@gmail.com" target="_blank">fwierzbicki@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Fri, Jun 8, 2012 at 9:22 AM, Jeff Hardy <<a href="mailto:jdhardy@gmail.com">jdhardy@gmail.com</a>> wrote:<br>
> On Fri, Jun 8, 2012 at 8:13 AM, Matti Picus <<a href="mailto:matti.picus@gmail.com">matti.picus@gmail.com</a>> wrote:<br>
>><br>
>> The windows port of pypy makes special demands on stdlib, specifically that<br>
>> files are explicitly closed. There are some other minor issues, in order to<br>
>> merge all the changes necessary to get pypy windows up to speed, around 10<br>
>> modules or at least their tests seem to need to be modified.<br>
>> I have been doing a bit of work on the stdlib shipped with pypy 1.9<br>
>> (version 2.7.2 unfortunately) to make it compliant. Assuming there is interest,<br>
>> what would be the best path to get, for instance, a modified version of<br>
>> mailbox.py with its tests (test_mailbox.py and test_old_mailbox.py) backported<br>
>> to cpython?<br>
><br>
> These fixes would also be useful for IronPython and possibly Jython as<br>
> well. Unclosed files are probably the biggest set of failures when<br>
> running CPython's tests on IronPython (along with assuming that<br>
> sys.platform == 'win32' means Windows). Whether or not they get<br>
> backported to CPython, it might be worth finding a way to share the<br>
> 2.7 stdlib between the alternative implementations (changes to 3.x<br>
> should go into CPython, obviously).<br>
</div>I think it's supposed to be alright to push changes to CPython's 2.7<br>
*tests* (like test_mailbox.py) but not other parts of the standard<br>
library (like mailbox.py)</blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-- I'd love to find a way to share the<br>
modifications from various implementations though -- and in the 3.x<br>
future hopefully it can all just end up in CPython's Lib.<br></blockquote><div><br></div><div>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 <a href="http://hg.python.org">hg.python.org</a> (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.</div>
<div><br></div><div>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.</div>
</div>