Why no warnings when re-assigning builtin names?

[Seebs]

On 2011-08-16, Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote:
> On Tue, 16 Aug 2011 01:23 pm Philip Semanchuk wrote:
>>> Why should built-ins be treated as more sacred than your own objects?
 
>> Because built-ins are described in the official documentation as having a
>> specific behavior, while my objects are not.

> *My* objects certainly are, because I write documentation for my code. My
> docs are no less official than Python's docs.

Sure they are.  I can't get yours from python.org.

> You can shadow anything. Sometimes shadowing is safe, sometimes it isn't. I
> don't see why we should necessarily fear safe shadowing of built-ins more
> than we fear unsafe shadowing of non-built-ins.

I think largely because anyone coming to your code will have expectations
about the built-ins.  For non-built-ins, they'll have to look around the code
to see what they do, but for built-ins, they come to the table with an
otherwise-reasonable expectation that they already know what that word means.

> 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. A warning that is on by
> default will be helpful to the newbie programmer for the first week or so,
> and then will be nothing but an annoyance for the rest of their career.

Will it?

I am pretty sure that I'd keep it on and fix anything that triggered it,
because shadowing built-ins strikes me as Asking For Trouble.

> 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?

I would distinguish between "may not be causing bugs" and "may be harmless".

I think code which shadows a built-in has a pretty real risk of being
harmful at some unspecified future point when some maintainer who hasn't
memorized every last line of the code makes the totally reasonable assumption
that basic language features are still working and available.

> 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, and for those that do, once they get bitten *once* they
> either never do it again or learn how to shadow safely. I don't see it as a
> problem.

I would guess that it happens moderately often entirely by accident.

Not a Python example, but I recently had a heck of a time with some
JavaScript I was trying to maintain.  Couldn't get it to work on a slightly
older Firefox, and the diagnostics from Firebug came across as basically
illucid.

Problem:  I was declaring an array named 'history'.

My thoughts would be:
1.  It's hard to avoid shadowing anything unless you know the entire language
and never forget things.
2.  In particular, Python likes to use clear, obvious, names for things.
Meaning that your choice of a clear, obvious, name for a similar thing
could be the name of a thing in the language.
3.  I am not sure at all that shadowing can be "safe" in code which will
some day be maintained.

The chances of someone coming along and trying to write clean, idiomatic,
Python which happens to blow up interestingly because their code runs in
an environment where part of the standard language has been shadowed
strike me as Too High.

MHO, but speaking only for myself, I'd want that warning on and I'd not
consider it harmless.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam at seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.