Why no warnings when re-assigning builtin names?

[Philip Semanchuk]

On Aug 16, 2011, at 1:15 AM, Steven D'Aprano wrote:

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

I'm sure they are no less official to you. But you are you, and then there's...everyone else. =) 

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. 


> Sometimes shadowing is safe, sometimes it isn't. 

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

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

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. 


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

One need look no further than the standard library to see a strong counterexample. grep through the Python source for " file =". 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. 

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.  (<=== How many builtins did I use in that sentence?)

Cheers
Philip