<div dir="ltr"><div>Aha. Glad I asked. You would arguably get a more useful response if you asked on core-mentorship and explained some of that background (for those of us who rely on external memory :-).<br><br></div>The stdlib intentionally makes what you are trying to do hard (so library writers don't have to worry about stdlib modules being overridden with hacks at the whim of other library writers or app writers).<br><br>I'm not sure how commit privileges would help you -- can't you just fork the CPython (I'm sure there's already a Bitbucket mirror that you can fork easily) and do your work there? Even with commit privileges you wouldn't be committing partial work unreviewed.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 14, 2015 at 12:07 PM, Demian Brecht <span dir="ltr"><<a href="mailto:demianbrecht@gmail.com" target="_blank">demianbrecht@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2015-01-14 11:35 AM, Guido van Rossum wrote:<br>
> Why do you want to hack the existing http modules?<br>
><br>
> This is not a rhetorical question. The answer may lead us to redesign the<br>
> existing http modules to be more flexible so that the higher-level problem<br>
> you are trying to solve by hacking http import can be solved instead by<br>
> using an interface provided by the stdlib http module.<br>
<br>
</span>Sorry, this venture began in core-mentorship, so a little context may be<br>
of use: My end goal is to become a maintainer of the http package.<br>
As I'm not a core dev, Nick had suggested making a friendly fork of the<br>
package in order to facilitate progress without being bound to the<br>
non-core dev contributor workflow (it can, at times, be a little painful<br>
getting reviews and such completed on orphaned packages).<br>
<br>
So, the question that I was trying to answer isn't directly related to<br>
the http package in particular, but how to override stdlib modules in<br>
general with a third party package in order to facilitate out of band<br>
development while making minimal changes to package code (i.e. changing<br>
all absolute import package names in test and module code) to ease<br>
upstream merging.<br>
<br>
That all said, this would likely be a moot issue if I had commit<br>
privileges ;) But it might be nice to figure out a good workflow should<br>
this come up again with any other new contributors looking to take<br>
ownership of an orphaned module.<br>
<br>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)</div>
</div>