Why no warnings when re-assigning builtin names?
philip at semanchuk.com
Wed Aug 17 02:18:02 CEST 2011
On Aug 16, 2011, at 7:29 PM, Terry Reedy wrote:
> On 8/16/2011 1:15 PM, Gerrat Rickert wrote:
>> I think that best practices would suggest that one shouldn't use
>> names that shadow builtins (except in specific, special circumstances),
>> so I don't really think this would be an annoyance at all. The number
>> *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.
> If you run across that again and email me the link, I will take a look and see if I think the issue should be raised on pydev. Of course, some modules *intentionally* define an open function, intended to be accessed as 'mod.open' and not as 'from mod import *; open'. Also, class/instance attributes can also reuse builtin names. But 'open = <True/False>' would be bad.
To generalize from your example, are you saying that there's a mild admonition against shadowing builtins with unrelated variable names in standard lib code?
Here's an example from Python 3.2.1's argparse.py, lines 466-473. "open" is shadowed on the second line.
# clean up separators for mutually exclusive groups
open = r'[\[(]'
close = r'[\])]'
text = _re.sub(r'(%s) ' % open, r'\1', text)
text = _re.sub(r' (%s)' % close, r'\1', text)
text = _re.sub(r'%s *%s' % (open, close), r'', text)
text = _re.sub(r'\(([^|]*)\)', r'\1', text)
text = text.strip()
More information about the Python-list