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

[Laura Creighton]

In a message of Mon, 02 Nov 2015 02:44:10 +1100, "Steven D'Aprano" writes:
>On Sun, Nov 01, 2015 at 08:53:17AM +0100, Laura Creighton wrote:
>> In a message of Sun, 01 Nov 2015 17:06:30 +1100, "Steven D'Aprano" writes:
>but that still allows accidental shadowing of third-party packages. I 
>don't think that the problem of accidently shadowing numpy is less 
>deserving of a solution than accidently shadowing random. They're both 
>problems.

And I do.

seriously.  I think that shadowing third party packages is something
I do all the time.  I am not willing to share a namespace with all
the package writers in the universe, and should I write package
name with the same name as somebody else's  third party package,
I damn well want mine, not some other one.

But learners shadowing the stdlib are a separate case.

We've had similar arguments before, the slipperly slope sort.
Either you don't want to solve any unless all get solved, or
else you are afraid that minor precedent here will lead to
all hell breaking loose when it is extended to its ultimate
conclusion.

But I think the entire purpose of being a human being is to
make such judgments.  And I think that this is an easy one.
Shadowing the stdlib can be treated as a catchable mistake.
Shadowing an outside package is something we want to do all the
time.

>> 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?
>
>Now just a minute, I'm not proposing that this change occur at random, 
>in the middle of a debugging session. Not even in a point (micro) 
>release. So the code will only break (if it breaks) when you upgrade 
>from version 3.x to 3.6 or higher. Moving to a new minor version number 
>is a big step, and people expect that things *could* break.

Ah, I think your thinking is less than clear on this one.

1. my sysadmin does an update and suddently the system python is a
different one than the one where I wrote my code.

some poor sysadmin soul who never wrote anything gets to deal
with the fact that my code now has name conflicts with
packages that we have, but I never knew about and never imported.

2. things fall over because the new verision of python,
in effect, shadows my code.

I am not willing to share my namespace with every other python
package creator on the planet.

I am a consultant.  When my code breaks, they call me.  I am 
unwilling to have my code break every time some human being
decides to make a package named something I already used over
the last 18 years of writing python code.  (I know that
3.x has not been out that long, but 18 years from now, 
the same condition holds.)

Laura