Why no warnings when re-assigning builtin names?

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

Hi Terry,
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 mailing list