On Tue, Aug 16, 2011 at 3:13 PM, Philip Semanchuk <phi...@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 -- http://mail.python.org/mailman/listinfo/python-list