[Python-ideas] [Python-Dev] If you shadow a module in the standard library that IDLE depends on, bad things happen

Alexander Walters tritium-list at sdamon.com
Sun Nov 1 08:25:54 EST 2015


Honestly, shadowing modules is something that should be solved by 
renaming modules.  If you are worrying about shadowing ONLY the standard 
library - guess what?  those names don't change often, and are well 
known.  Don't use those names.  If you are talking about shadowing 
site-packages, or any package anywhere on sys.path, you are bound to 
break something somewhere in a hard to debug way.  It is sufficient to 
allow things to break and instruct people to jump in the repl, import a 
module and check __file__.

On 11/1/2015 02:58, Chris Angelico wrote:
> On Sun, Nov 1, 2015 at 6:53 PM, Laura Creighton <lac at openend.se> wrote:
>> In a message of Sun, 01 Nov 2015 17:06:30 +1100, "Steven D'Aprano" writes:
>>
>>> I propose the following two changes:
>>>
>>>
>>> (1) Beginning with Python 3.6, the default is that the current directory
>>> is put at the end of sys.path rather than the beginning. Instead of:
>>>
>>>     >>> print(sys.path)
>>>     ['', '/this', '/that', '/another']
>>>
>>> we will have this instead:
>>>
>>>     >>> print(sys.path)
>>>     ['/this', '/that', '/another', '']
>>>
>>> Those who don't shadow installed packages won't notice any
>>> difference.
>>>
>>> Scripts which deliberately or unintentionally shadow installed packages
>>> will break from this change. I don't have a problem with this. You can't
>>> fix harmful behaviour without breaking code that depends on that harmful
>>> behaviour.
>> This is a bad idea, if you mean 'shadows anything in site-packages'.
>> I write a perfectly good working program, which then silently breaks
>> because somebody happens to install a site package with a name
>> conflict with my code.  Can you imagine being in the middle of
>> writing and debugging such a thing and have everything start
>> failing because suddenly your program isn't the one being found?
>> How long is it going to take you to stop looking at your own code,
>> and your own setup for the problem and begin looking at what
>> packages got installed by anybody else sharing this machine, and
>> what they are named?
> I'm fairly sure Steven's talking about the standard library, not
> arbitrary packages people might happen to have installed. Whether he
> thought about it or not, the solution to both your problems seems to
> be this:
>
> sys.path = ['/usr/local/lib/python36.zip', '/usr/local/lib/python3.6',
> '/usr/local/lib/python3.6/plat-linux',
> '/usr/local/lib/python3.6/lib-dynload', '',
> '/home/rosuav/.local/lib/python3.6/site-packages',
> '/usr/local/lib/python3.6/site-packages']
>
> Equivalently, for the system Python:
>
> sys.path = ['/usr/lib/python3.4',
> '/usr/lib/python3.4/plat-x86_64-linux-gnu',
> '/usr/lib/python3.4/lib-dynload', '',
> '/usr/local/lib/python3.4/dist-packages',
> '/usr/lib/python3/dist-packages']
>
>
> So the current directory is after everything that's logically the
> standard library, but before things that would be installed separately
> (site-packages, dist-packages, etc). It'd no longer be possible to
> shadow wave.py, but you could shadow sqlalchemy.py.
>
> ChrisA
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/



More information about the Python-ideas mailing list