> On Aug 16, 2011, at 1:15 AM, Steven D'Aprano wrote: ... > A warning that is off by default won't help the people who need it, > because > they don't know enough to turn the warning on. A warning that is on by > default will be helpful to the newbie programmer for the first week or > so, > and then will be nothing but an annoyance for the rest of their career. >
I think that best practices would suggest that one shouldn't use variable names that shadow builtins (except in specific, special circumstances), so I don't really think this would be an annoyance at all. The number of *unwanted* warnings they'd get would be pretty close to zero. OTOH, in response to a question I asked on StackOverflow, someone posted a large list of times where this isn't followed in the std lib, so there seems to be a precedent for just using the builtin names for anything one feels like at the time. Thinking about it, what about if, by default, python was configured to emit warnings about this sort of thing, but a simple environment variable or config option would turn them off. That way, new users would get warnings when doing this sort of thing, and any experienced user that wanted the option of using these variables anywhere would just have a one-time thing to change when they installed python (or any time later). They'd turn these warnings off when they installed Python, and would never have to think about it again. New users (or experienced ones that prefer this) would be warned by default, and then could make the conscious decision to shadow the builtin names, instead of accidentally doing it. All the suggestions to just use a linter aren't helpful, since new users aren't likely to start with one & and they are the thrust of this discussion. -- http://mail.python.org/mailman/listinfo/python-list