Why no warnings when re-assigning builtin names?

Gerrat Rickert grickert at coldstorage.com
Tue Aug 16 19:15:04 CEST 2011


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




More information about the Python-list mailing list