[Python-Dev] Overriding stdlib http package

[Donald Stufft]

> On Jan 24, 2015, at 2:57 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> On 15 January 2015 at 07:35, Donald Stufft <donald at stufft.io> wrote:
>> 
>> On Jan 14, 2015, at 4:19 PM, Brett Cannon <brett at python.org> 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.
>> 
>> Not all of us, I hate the default order of sys.path.
> 
> It's mostly an opinion that arises from debugging other people's
> problems after they've managed to import the wrong thing without
> realising it (cf. the "don't use 'socket.py' as the name of your
> script for learning about how TCP sockets work" problem). We're aware
> that annoys power users, but they're far better equipped to handle the
> problem than if we inverted the situation.


It’s not just power users that it’s good for, it makes it harder for
even beginners to use things like backports of modules. For example
unittest2 and explaining to people the difference between unittest and
unittest2 and that unittest2 isn’t actually any different than unittest
on newer versions of Python.

Or, for example, PEP 453 could have been like 100x better if it would
have been reasonable to just add pip to the stdlib but still enabling
the ability to install an upgraded version of it that would take precedence.

Or you have things like pdb++ which needs to replace the pdb import
because a lot of tools only have a flag like —pdb and do not provide
a way to switch it to a different import. The sys.path ordering means
that pdb++ has to do hacks in its setup.py[1] which means it won’t be
compatible with Wheel files or with a world where sdists don’t use
a setup.py.

The current situation is that if you install something as an egg (which
setuptools does by default anyways) then setuptools will put it before
the stdlib and it’ll take precedence. This is a nice situation because
it means that if you do run into a problem then it’s easier to debug
because ``python -c import module; print(module.__file__)`` will always
return the same answer in the “broken” environment. The alternative is
often either a different name (which confuses people as to the relation)
or monkey patching which means that module.__file__ might either be wrong
if they just monkey patched the file and it always means that the behavior
is going to change depending on what you’ve imported which is way more
confusing then being able to override the stdlib.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA