Why no warnings when re-assigning builtin names?

[Tim Chase]

On 08/16/2011 10:31 AM, Philip Semanchuk wrote:
> On Aug 16, 2011, at 11:12 AM, Chris Angelico wrote:
>> There are several types of shadowing:
>>
>> 1) Deliberate shadowing because you want to change the behavior of the
>> name. Extremely rare.
>> 2) Shadowing simply by using the name of an unusual builtin (like
>> 'file') in a context where you never use it. Very common.
>> 3) Unintentional shadowing where you create a variable, but then
>> intend to use the builtin. This is the only one that's a
>> problem.
>
> Yes, but before you get to #3 you have to go through #2. The
> way I see it, #2 is setting a trap, #3 is actually stepping
> in it. I don't want to do either. Neither do I like working
> with code that has set trap #2 for me.

Chris succinctly described the times I've done shadowing. 
Fortunately, the shadowing done in #3 (which you appropriately 
describe as being a superset of #2) is fairly remedied with most 
editors...since it usually occurs when you have "oh, I 
accidentally shadowed builtin X", so you just do a global 
search-and-replace for all those places you shadowed X and rename 
it to something like "my_X" and proceed to use X as the builtin.

The bigger issue I have is module shadowing which is trickier to 
catch and produces weird symptoms (i.e. cryptic errors).  The 
most common one I see is creating a local module called 
"email.py" and then having issues when trying to use 
standard-library email calls which find your local email.py 
before they find the email.py file in the standard library.  I 
actually wrote a tool to scan for duplicate modules in 
$PYTHONPATH (pretty dumb tool, could easily have broken on things 
like zipfile imports, DLLs, etc), but it made diagnosing the 
issue easier.

-tkc