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()
Thanks
Philip
--
http://mail.python.org/mailman/listinfo/python-list
