Why no warnings when re-assigning builtin names?

[Steven D'Aprano]

On Tue, 16 Aug 2011 01:23 pm Philip Semanchuk wrote:

> 
> On Aug 15, 2011, at 9:32 PM, Steven D'Aprano wrote:
> 
>> On Tue, 16 Aug 2011 08:15 am Chris Angelico wrote:
>> 
>>> 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.
>> 
>> Agreed. It's a style issue, nothing else. There's nothing worse about:
>> 
>> def spam(list):
>>    pass
>> 
>> compared to
>> 
>> class thingy: pass
>> 
>> def spam(thingy):
>>    pass
>> 
>> 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.

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'm not even convinced that making None a reserved word was the right
decision.)

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.

(For some definition of a week -- some people are slower learners than
others.)


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

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? Beginners often lack the skill to distinguish between
harmless warnings that can safely be ignored, and fatal errors that need to
be fixed. Even "user friendly" warning or error messages tend to unnerve
some beginner coders.

There's not much we can do about outright errors, except to make sure that
the error string is as useful as possible, but we can avoid overloading
beginners with warnings they don't need to care about:


    WARNING WARNING WARNING WILL ROBINSON, DANGER DANGER DANGER:
    YOUR SISTER'S NAME 'PENNY' SHADOWS THE BRITISH CURRENCY, 
    POTENTIAL AMBIGUITY ALERT DANGER DANGER DANGER!


*wink*

Depending on their personality, you may end up teaching them to ignore
warnings, or a superstitious dread of anything that leads to a warning.
Neither is a good outcome.


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

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.



-- 
Steven