<br><br><div class="gmail_quote">On Wed Jan 14 2015 at 4:58:20 PM Demian Brecht <<a href="mailto:demianbrecht@gmail.com">demianbrecht@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2015-01-14 1:19 PM, Brett Cannon wrote:<br>
> But as Guido pointed out, we _like_ it being difficult to do because we<br>
> don't want this kind of substitution happening as code ends up depending on<br>
> bugs and quirks that you may fix.<br>
<br>
I can understand the reasoning.<br>
<br>
> How many other modules are dependent on the http module in the stdlib that<br>
> are going to be affected by your changes? One option is you fork http<br>
> **and** and modules in the stdlib that are dependent on it. You don't<br>
> really have to change the other modules beyond their import statement of<br>
> using http -- you can even do `import http3 as http` or something to<br>
> minimize the changes -- but you at least don't have to monkeypatch<br>
> sys.modules for others to gain from your http changes. Plus as you patch<br>
> stuff in http you may find you have/want to patch other dependent modules<br>
> as well and so you will have already done that.<br>
<br>
It looks like there are 5 other modules dependent on the http package.<br>
If I understand what you're proposing, it pretty much defeats the<br>
purpose of what I'm trying to accomplish with a standalone httplib3 package.<br>
<br>
That said, considering the points that you and Guido have both made, I<br>
think that the best course of action is to either just fork CPython as a<br>
whole or to continue with httplib3 but abandon overriding sys.modules,<br>
develop features detached from the stdlib and worry about fixing<br>
dependencies when integrating changes upstream.<br></blockquote><div><br></div><div>If I were you I would fork and then for bugfixes send them upstream to us while you develop API additions independently. That way if your fork gains traction you can come to us and say "my fork has a stable API, has existed for (at least) a year, and the community seems to have rallied behind it", at which point we can look at drawing it in. And if you fix enough bugs we might make you maintainer anyway while you work out API design with the community outside of the stdlib.<br></div></div>