anomaly

[Steven D'Aprano]

On Tue, 12 May 2015 09:55 pm, Antoon Pardon wrote:

> Op 11-05-15 om 16:13 schreef Chris Angelico:
> 
>> Why does Python have most built-ins as simply looked-up names that can
>> be overridden? Because otherwise, there would be a veritable ton of
>> keywords:
> 
> But that doesn't answer the question why the developers chose "True" to be
> a keyword and "int" to be a looked-up name.

No it doesn't. But then, nobody until now has *asked* that question, merely
commented on it as a fact.

If you go all the way back to Python 1.5, not only did True and False not
exist as built-ins, but None was not a keyword:


[steve at ando ~]$ python1.5
Python 1.5.2 (#1, Aug 27 2012, 09:09:18)  [GCC 4.1.2 20080704 (Red Hat
4.1.2-52)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> None = 23
>>> [].sort() is None
0
>>> print None
23


The consensus among the core developers is:

* in general, the harm and inconvenience from accidentally
  shadowing built-ins is not great, and it usually easy to
  spot, debug and prevent;

* when it comes to built-in functions (e.g. sum, map, pow)
  and types (e.g. int, str, list) there are significant and
  important use-cases for allowing shadowing;

  (e.g. the built-in sum function shouldn't prevent other
  modules from providing their own sum function)

* but when it comes to None, True and False, there are no
  significant or important use-cases for shadowing (it is 
  almost always a bug, not a feature, to redefine None).

The general principle here is of consenting adults: Python allows you to
shadow built-ins because sometimes it is useful, and the good outweighs the
potential harm. There are a handful of exceptions to that general principle
(e.g. None, True, False, I can't think of any others) because in those
cases the harm (as tiny as it is) outweighs the good.



> and pretending to justify that choice by stating that the python thought
> is: We're all adults here, if you want to override a builtin, who are we
> to stop you. That is disingenuous.

No, it's quite sensible, given Python's stated position: it's not an
authoritarian B&D language like Pascal, nor is it a permissive "anything
goes" language like C. It takes a middle ground, protecting you from the
worst consequences (no seg faults), but otherwise you're trusted to look
after yourself.

To give an analogy, you can consent to having a boxing match, with rules, a
referee, and clear limits on what force is permissible, but you cannot
legally consent to a duel to the death.



-- 
Steven