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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com