Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!feeder.news-service.com!feeder.news-service.com!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Return-Path: <philip@semanchuk.com>
X-Original-To: python-list@python.org
Delivered-To: python-list@mail.python.org
X-Spam-Status: OK 0.000
X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; '(except': 0.05; 'attributes': 0.05; 'warnings': 0.05; 'builtins': 0.07; 'function,': 0.07; 'names.': 0.07; 'raised': 0.07; 'subject:when': 0.07; 'terry': 0.07; 'python': 0.08; 'builtin': 0.09; '16,': 0.15; "'open": 0.16; 'code?': 0.16; 'otoh,': 0.16; 'received:mindspring.com': 0.16; 'reedy': 0.16; 'subject:builtin': 0.16; 'terry,': 0.16; 'x-mailer:apple mail (2.1084)': 0.16; 'wrote:': 0.16; 'seems': 0.20; 'suggest': 0.20; 'header:In-Reply- To:1': 0.22; "shouldn't": 0.23; 'asked': 0.23; 'pm,': 0.24; 'variable': 0.24; 'aug': 0.24; 'saying': 0.26; 'posted': 0.26; 'skip:_ 20': 0.28; 'import': 0.28; 'second': 0.29; 'example': 0.30; 'lines': 0.30; 'zero.': 0.30; 'thanks': 0.30; 'modules': 0.31; 'subject:?': 0.31; 'list': 0.32; 'received:24': 0.32; "isn't": 0.33; 'there': 0.33; 'to:addr:python-list': 0.33; 'someone': 0.34; 'all.': 0.34; 'pretty': 0.35; 'anything': 0.36; 'charset:us-ascii': 0.36; 'question': 0.36; 'issue': 0.36; 'example,': 0.37; 'response': 0.37; 'using': 0.37; 'run': 0.37; 'but': 0.37; 'open': 0.37; 'think': 0.38; 'some': 0.38; 'should': 0.38; 'subject:: ': 0.39; 'header:Mime-Version:1': 0.39; "there's": 0.39; 'define': 0.39; 'to:addr:python.org': 0.39; 'where': 0.40; 'your': 0.61; 'header:Message-Id:1': 0.61; 'special': 0.67; 'exclusive': 0.78; 'received:69.73': 0.84; 'specific,': 0.84; 'open,': 0.91
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: Why no warnings when re-assigning builtin names?
From: Philip Semanchuk <philip@semanchuk.com>
In-Reply-To: <j2euh6$f3s$1@dough.gmane.org>
Date: Tue, 16 Aug 2011 20:18:02 -0400
Content-Transfer-Encoding: quoted-printable
References: <BB13E4C4D649234F84A01F6DF64BB87F076AD0CE@ccs-ex01.coldstorage.com><mailman.22.1313446504.27778.python-list@python.org><4e49c89a$0$30001$c3e8da3$5496439d@news.astraweb.com><mailman.34.1313464992.27778.python-list@python.org> <4e49fcd7$0$29974$c3e8da3$5496439d@news.astraweb.com> <BB13E4C4D649234F84A01F6DF64BB87F076AD33B@ccs-ex01.coldstorage.com> <j2euh6$f3s$1@dough.gmane.org>
To: python-list list <python-list@python.org>
X-Mailer: Apple Mail (2.1084)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - deimos.nocdirect.com
X-AntiAbuse: Original Domain - python.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - semanchuk.com
X-BeenThere: python-list@python.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion list for the Python programming language <python-list.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/options/python-list>, <mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/python-list>
List-Post: <mailto:python-list@python.org>
List-Help: <mailto:python-list-request@python.org?subject=help>
List-Subscribe: <http://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe>
Newsgroups: comp.lang.python
Message-ID: <mailman.108.1313540287.27778.python-list@python.org>
Lines: 50
NNTP-Posting-Host: 2001:888:2000:d::a6
X-Trace: 1313540287 news.xs4all.nl 23929 [2001:888:2000:d::a6]:48205
X-Complaints-To: abuse@xs4all.nl
Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:11633


On Aug 16, 2011, at 7:29 PM, Terry Reedy wrote:

> On 8/16/2011 1:15 PM, Gerrat Rickert wrote:
>=20
>> 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.
>=20
> 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 =3D <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 =3D r'[\[(]'
        close =3D r'[\])]'
        text =3D _re.sub(r'(%s) ' % open, r'\1', text)
        text =3D _re.sub(r' (%s)' % close, r'\1', text)
        text =3D _re.sub(r'%s *%s' % (open, close), r'', text)
        text =3D _re.sub(r'\(([^|]*)\)', r'\1', text)
        text =3D text.strip()


Thanks
Philip