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@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 -- https://mail.python.org/mailman/listinfo/python-list
