Why no warnings when re-assigning builtin names?

Ethan Furman ethan at stoneleaf.us
Tue Aug 16 17:41:08 CEST 2011

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 
 > 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 

>> 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 
> 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.


More information about the Python-list mailing list