<br><br><div class="gmail_quote">On Fri, Nov 25, 2011 at 12:37, Antoine Pitrou <span dir="ltr"><<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="HOEnZb"><div class="h5">On Fri, 25 Nov 2011 12:37:59 -0500<br>
Brett Cannon <<a href="mailto:brett@python.org">brett@python.org</a>> wrote:<br>
> On Thu, Nov 24, 2011 at 07:46, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
><br>
> > On Thu, Nov 24, 2011 at 10:20 PM, Maciej Fijalkowski <<a href="mailto:fijall@gmail.com">fijall@gmail.com</a>><br>
> > 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>
> > 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>
> ><br>
><br>
> And the other reason I plan to see this through before I die<br>
<br>
</div></div>Uh! Any bad news? :/</blockquote><div><br></div><div><br></div><div>Sorry, turn of phrase in English which didn't translate well. I just meant "when I get to it, which could quite possibly be a *long* time from now". This year has been absolutely insane for me personally (if people care, the details are shared on Google+ or you can just ask me), so I am just not promising anything for Python on a short timescale (although I'm still hoping the final details for bootstrapping importlib won't be difficult to work out so I can meet a personal deadline of PyCon).</div>
</div>