Why no warnings when re-assigning builtin names?

[Chris Angelico]

On Tue, Aug 16, 2011 at 3:13 PM, Philip Semanchuk <philip at semanchuk.com> wrote:
> I am an example. I know enough to turn the theoretical warning on, and I would if I could. I have never shadowed a builtin deliberately. I've done it accidentally plenty of times. There are 84 builtins in my version of Python and I don't have them all memorized. The fact that my editor colors them differently is the only thing I have to back up my leaky memory. Not all editors are so gracious.
>

Rather than "turn a warning on" you can "run your code through a
linting script". There are several excellent ones. Add it to your
makefile or test suite; then you get the testing done over _all_ of
your code, instead of waiting until the moment when you actually
execute it.

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

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.

list = [...]
is not a problem unless you later on use
foo = list(map(...))
which is more common in Python 3 than Python 2, but fortunately, it'll
throw a nice quick error - nobody's going to use list operations on
the normal 'list' type, nor is anybody going to call an instance of
list.

Definitely a job for linting.

ChrisA