Why no warnings when re-assigning builtin names?

[Philip Semanchuk]

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.

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. 

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. 

bye,
Philip