Why no warnings when re-assigning builtin names?

[Ethan Furman]

Philip Semanchuk wrote:
> On Aug 16, 2011, at 1:15 AM, Steven D'Aprano wrote:
>> Protecting n00bs from their own errors is an admirable aim, but have you
>> considered that warnings for something which may be harmless could do more
>> harm than good?
> 
> Isn't the whole point of a warning to highlight behavior that's not strictly
 > wrong but looks iffy? Sort of, "I can't be sure, but this looks like 
trouble
 > to me. I hope you know what you're doing". If we are to eschew 
warnings in
 > cases where they might be highlighting something harmless, then we would
 > have no warnings at all.

Sounds good to me.  ;)  Keep such things in the IDE's, and then those 
who desire such behavior can have it there.  Do not clutter Python with 
such.

>> Perhaps. But I'm not so sure it is worth the cost of extra code to detect
>> shadowing and raise a warning. After all, the average coder probably never
>> shadows anything,
> 
> One need look no further than the standard library to see a strong
 > counterexample. grep through the Python source for " file =". I see 
dozens
> of examples of this builtin being used as a common variable name. I would
 > call contributors to the standard library above-average coders, and 
we can
 > see them unintentionally shadowing builtins many times.

What makes you think it's unintentional?  file makes a good variable 
name, and if you don't need it to actually open a file there's nothing 
wrong with using it yourself.


>> and for those that do, once they get bitten *once* they
>> either never do it again or learn how to shadow safely.
> 
> I have done it plenty of times, never been bitten (thankfully) and still
 > do it by accident now and again.

Seems to me the real issue is somebody using a builtin, such as str or 
int, and that they somehow manage to do this without realizing, "wait a 
sec', that's one of my variables!"  I don't see that as a problem that 
Python needs to solve.

~Ethan~