On 2015-01-14 1:19 PM, Brett Cannon wrote:
But as Guido pointed out, we _like_ it being difficult to do because we don't want this kind of substitution happening as code ends up depending on bugs and quirks that you may fix.
I can understand the reasoning.
How many other modules are dependent on the http module in the stdlib that are going to be affected by your changes? One option is you fork http **and** and modules in the stdlib that are dependent on it. You don't really have to change the other modules beyond their import statement of using http -- you can even do `import http3 as http` or something to minimize the changes -- but you at least don't have to monkeypatch sys.modules for others to gain from your http changes. Plus as you patch stuff in http you may find you have/want to patch other dependent modules as well and so you will have already done that.
It looks like there are 5 other modules dependent on the http package. If I understand what you're proposing, it pretty much defeats the purpose of what I'm trying to accomplish with a standalone httplib3 package.
That said, considering the points that you and Guido have both made, I think that the best course of action is to either just fork CPython as a whole or to continue with httplib3 but abandon overriding sys.modules, develop features detached from the stdlib and worry about fixing dependencies when integrating changes upstream.