Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!feeder.news-service.com!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
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: <4e49fcd7$0$29974$c3e8da3$5496439d@news.astraweb.com>
Date: Tue, 16 Aug 2011 10:13:36 -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>
To: Lista-Comp-Lang-Python list <python-list@python.org>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.61.1313504028.27778.python-list@python.org>
Lines: 150
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:11553


On Aug 16, 2011, at 1:15 AM, Steven D'Aprano wrote:

> On Tue, 16 Aug 2011 01:23 pm Philip Semanchuk wrote:
>=20
>>=20
>> On Aug 15, 2011, at 9:32 PM, Steven D'Aprano wrote:
>>=20
>>> On Tue, 16 Aug 2011 08:15 am Chris Angelico wrote:
>>>=20
>>>> If you want a future directive that deals with it, I'd do it the =
other
>>>> way - from __future__ import mask_builtin_warning or something - so
>>>> the default remains as it currently is. But this may be a better =
job
>>>> for a linting script.
>>>=20
>>> Agreed. It's a style issue, nothing else. There's nothing worse =
about:
>>>=20
>>> def spam(list):
>>>   pass
>>>=20
>>> compared to
>>>=20
>>> class thingy: pass
>>>=20
>>> def spam(thingy):
>>>   pass
>>>=20
>>> Why should built-ins be treated as more sacred than your own =
objects?
>>=20
>> Because built-ins are described in the official documentation as =
having a
>> specific behavior, while my objects are not.
>=20
> *My* objects certainly are, because I write documentation for my code. =
My
> docs are no less official than Python's docs.

I'm sure they are no less official to you. But you are you, and then =
there's...everyone else. =3D)=20

I (and I think most people) give far more credibility to the Python docs =
than to the documentation of an individual. That's not a reflection on =
you, it reflects the limits of one person's ability versus =
organizationally produced docs which are heavily used, discussed, and =
have been iteratively developed over many years.=20


> Sometimes shadowing is safe, sometimes it isn't.=20

"Sometimes X is safe and sometimes it isn't" can be said of many, many =
things, from taking a walk down the street to juggling with knives. But =
it has little to do with whether or not Python should issue a warning in =
the specific case we're talking about.


> 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.

I agree that it wouldn't help the people who need it most (absolute raw =
newcomers). But you're asserting that once one learned the incantation =
to enable the theoretical warning we're discussing, one would have =
graduated to a level where it's no longer useful. That's not the case. =
There's a lot of ground to cover between "newcomer who has learned about =
a particular warning" and "coder who regularly shadows builtins on =
purpose".=20

I am an example. I know enough to turn the theoretical warning on, and I =
would if I could. I have never shadowed a builtin deliberately. I've =
done it accidentally plenty of times. There are 84 builtins in my =
version of Python and I don't have them all memorized. The fact that my =
editor colors them differently is the only thing I have to back up my =
leaky memory. Not all editors are so gracious.


>> Yes, it can be useful to replace some of the builtins with one's own
>> implementation, and yes, doing so fits in with Python's "we're all
>> consenting adults" philosophy. But replacing (shadowing, masking -- =
call
>> it what you will) builtins is not everyday practice. On the contrary, =
as
>> the OP Gerrat pointed out, it's most often done unwittingly by =
newcomers
>> to the language who have no idea that they've done anything out of =
the
>> ordinary or potentially confusing.
>=20
> Protecting n00bs from their own errors is an admirable aim, but have =
you
> considered that warnings for something which may be harmless could do =
more
> harm than good?

Isn't the whole point of a warning to highlight behavior that's not =
strictly wrong but looks iffy? Sort of, "I can't be sure, but this looks =
like trouble to me. I hope you know what you're doing". If we are to =
eschew warnings in cases where they might be highlighting something =
harmless, then we would have no warnings at all.=20

Again, shadowing builtins is not everyday practice. I have been trying =
to remember if I've ever seen it done deliberately, and I can't remember =
a case. Now, a comment like that is an invitation for people come out of =
the woodwork with cases where they found it useful, and I would welcome =
some examples as I'm sure they'd be interesting. But I think it's safe =
to say that if you look at random samples of code, builtins are shadowed =
unintentionally hundreds of times for every time they're shadowed =
deliberately and usefully.=20


>> If a language feature is most often invoked accidentally without =
knowledge
>> of or regard for its potential negative consequences, then it might =
be
>> worth making it easier to avoid those accidents.
>=20
> Perhaps. But I'm not so sure it is worth the cost of extra code to =
detect
> shadowing and raise a warning. After all, the average coder probably =
never
> shadows anything,

One need look no further than the standard library to see a strong =
counterexample. grep through the Python source for " file =3D". I see =
dozens of examples of this builtin being used as a common variable name. =
I would call contributors to the standard library above-average coders, =
and we can see them unintentionally shadowing builtins many times.


> and for those that do, once they get bitten *once* they
> either never do it again or learn how to shadow safely.

I have done it plenty of times, never been bitten (thankfully) and still =
do it by accident now and again.=20

You can coerce any example to apply to an argument for or against such a =
warning, but I think the general case is that Python could reduce =
unintended consequences by warning when vars erase builtins.  (<=3D=3D=3D =
How many builtins did I use in that sentence?)

Cheers
Philip