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~
--
http://mail.python.org/mailman/listinfo/python-list
