<br><br><div class="gmail_quote">2011/11/25 Brett Cannon <span dir="ltr"><<a href="mailto:brett@python.org">brett@python.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><br><div class="gmail_quote"><div class="im">On Thu, Nov 24, 2011 at 07:46, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@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>On Thu, Nov 24, 2011 at 10:20 PM, Maciej Fijalkowski <<a href="mailto:fijall@gmail.com" target="_blank">fijall@gmail.com</a>> wrote:<br>
> The problem is not with maintaining the modified directory. The<br>
> problem was always things like changing interface between the C<br>
> version and the Python version or introduction of new stuff that does<br>
> not run on pypy because it relies on refcounting. I don't see how<br>
> having a subrepo helps here.<br>
<br>
</div>Indeed, the main thing that can help on this front is to get more<br>
modules to the same state as heapq, io, datetime (and perhaps a few<br>
others that have slipped my mind) where the CPython repo actually<br>
contains both C and Python implementations and the test suite<br>
exercises both to make sure their interfaces remain suitably<br>
consistent (even though, during normal operation, CPython users will<br>
only ever hit the C accelerated version).<br>
<br>
This not only helps other implementations (by keeping a Python version<br>
of the module continuously up to date with any semantic changes), but<br>
can help people that are porting CPython to new platforms: the C<br>
extension modules are far more likely to break in that situation than<br>
the pure Python equivalents, and a relatively slow fallback is often<br>
going to be better than no fallback at all. (Note that ctypes based<br>
pure Python modules *aren't* particularly useful for this purpose,<br>
though - due to the libffi dependency, ctypes is one of the extension<br>
modules most likely to break when porting).<br></blockquote><div><br></div></div><div>And the other reason I plan to see this through before I die is to help distribute the maintenance burden. Why should multiple VMs fix bad assumptions made by CPython in their own siloed repos and then we hope the change gets pushed upstream to CPython when it could be fixed once in a single repo that everyone works off of?</div>
</div></blockquote><div><br></div><div>PyPy copied the CPython stdlib in a directory named "2.7", which is never modified; instead, adaptations are made by copying the file into "modified-2.7", and fixed there. Both directories appear in sys.path</div>
<div>This was done for this very reason: so that it's easy to identify the differences and suggest changes to push upstream.</div><div><br></div><div>But this process was not very successful for several reasons:</div>
<div><br></div><div>- The definition of "bad assumptions" used to be very strict. It's much much better nowadays, thanks to the ResourceWarning in 3.x for example (most changes in modified-2.7 are related to the garbage collector), and wider acceptance by the core developers of the "@impl_detail" decorators in tests.</div>
<div><br></div><div>- 2.7 was already in maintenance mode, and such changes were not considered as bug fixes, so modified-2.7 never shrinks. It was a bit hard to find the motivation to fix only the 3.2 version of the stdlib, which you can not even test with PyPy!</div>
<div><br></div><div>- Some modules in the stdlib rely on specific behaviors of the VM or extension modules that are not always easy to implement correctly in PyPy. The ctypes module is the most obvious example to me, but also the pickle/copy modules which were modified because of subtle differences around built-in methods (or was it the __builtins__ module?)</div>
<div>And oh, I almost forgot distutils, which needs to parse some Makefile which of course does not exist in PyPy.</div><div><br></div><div>- Differences between C extensions and pure Python modules are sometimes considered "undefined behaviour" and are rejected. See issue13274, this one has an happy ending, but I remember that the _pyio.py module chose to not fix some obscure reentrancy issues (which I completely agree with)</div>
<div><br></div></div>-- <br>Amaury Forgeot d'Arc<br>