Why no warnings when re-assigning builtin names?
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
> 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
> 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