> On Jan 24, 2015, at 2:57 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > > On 15 January 2015 at 07:35, Donald Stufft <don...@stufft.io> wrote: >> >> On Jan 14, 2015, at 4:19 PM, Brett Cannon <br...@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 _______________________________________________ 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