43

In Python 2, we could reassign True and False (but not None), but all three (True, False, and None) were considered builtin variables. However, in Py3k all three were changed into keywords as per the docs.

From my own speculation, I could only guess that it was to prevent shenanigans like this which derive from the old True, False = False, True prank. However, in Python 2.7.5, and perhaps before, statements such as None = 3 which reassigned None raised SyntaxError: cannot assign to None.

Semantically, I don't believe True, False, and None are keywords, since they are at last semantically literals, which is what Java has done. I checked PEP 0 (the index) and I couldn't find a PEP explaining why they were changed.

Are there performance benefits or other reasons for making them keywords as opposed to literals or special-casing them like None in python2?

Community
  • 1
  • 1
Snakes and Coffee
  • 8,747
  • 4
  • 40
  • 60

3 Answers3

48

Possibly because Python 2.6 not only allowed True = False but also allowed you to say funny things like:

__builtin__.True = False

which would reset True to False for the entire process. It can lead to really funny things happening:

>>> import __builtin__
>>> __builtin__.True = False
>>> True
False
>>> False
False
>>> __builtin__.False = True
>>> True
False
>>> False
False

EDIT: As pointed out by Mike, the Python wiki also states the following under Core Language Changes:

  • Make True and False keywords.
    • Reason: make assignment to them impossible.
Community
  • 1
  • 1
devnull
  • 118,548
  • 33
  • 236
  • 227
  • Wouldn't shenanigans like this still be stopped if `True` and `False` were like `None` instead of keywords? `>>> __builtin__.None = 5 SyntaxError: cannot assign to None` – Snakes and Coffee Aug 05 '13 at 05:34
  • Partial restrictions on `None` have existed since 2.6. – devnull Aug 05 '13 at 05:43
  • So if `True` and `False` were changed to be None-esque instead of keywords, it would work too, right? – Snakes and Coffee Aug 05 '13 at 05:45
  • 1
    It seems that there was a [time](http://mail.python.org/pipermail/python-3000/2007-January/005284.html) when they didn't want `True` and `False` to be reserved words, but apparently it changed :) – devnull Aug 05 '13 at 05:53
  • +1; according to the [python wiki](http://wiki.python.org/moin/Python3.0) it was to "make assignment to them impossible". – mpontillo Aug 08 '13 at 08:28
  • @Mike the question is why they chose to make them keywords, instead of making them immutable (a la None in py26+) – Snakes and Coffee Aug 08 '13 at 08:47
  • 2
    @SnakesandCoffee The move to make None a constant was temporary. See http://mail.python.org/pipermail/python-dev/2004-July/046294.html – devnull Aug 08 '13 at 09:06
  • Can't you still do `setattr(__builtin__, "False", True)`? – user541686 Aug 15 '13 at 03:28
  • @Mehrdad Did you mean `setattr(builtins, "False", True)` instead? That doesn't work in python 3.x. – devnull Aug 15 '13 at 06:33
  • @devnull: Ah yeah sure. It's not a syntax error though, my point is that making `True` and `False` keywords doesn't "prevent" assignment to them in any way that lets you avoid runtime checks... you still need checks for these situations. – user541686 Aug 15 '13 at 06:36
  • 1
    @Mehrdad: Even if you try `setattr(builtins, 'False', True)`, the expression `False` won't look up `builtins.False` for its value. The `False` keyword refers directly to the `False` object, not the value of an attribute in the builtins module. – user2357112 May 13 '14 at 05:00
12

For two reasons, mainly:

  1. So people don't do a __builtin__.True = False prank hidden on a random module. (as explained by devnull)
  2. Because keywords are faster than global builtins. In Python 2.x, the interpreter would have to resolve those variables' values before using them, which is a bit slower than keywords. (see Why is if True slower than if 1?)
This company is turning evil.
  • 5,021
  • 5
  • 34
  • 58
4

This was discussed some months ago on python-dev. Having tons of links to the definition of True would be annoying, contrary to links to e.g. the nonlocal or with statements doc.

And things I conclude why True and False will make things "even finer".

  1. re-bound as a side effect of functions called within the loop.

    It's really easy to change True, such as:

    def True(): print True

  2. There is really no good use case for letting user code rebind the built-in names None, True, and False, making them keywords has almost only pluses.

  3. Make program has to look-up "True" in symbol-table at each step just to find True has value True is far from intuitive. (that is why 1 is faster than True.)

    x=compile('while 1: foop()', '', 'exec')

    dis.dis(x)

          0 SETUP_LOOP              19 (to 22)
      3 JUMP_FORWARD             4 (to 10)
      6 JUMP_IF_FALSE           11 (to 20)
      9 POP_TOP
>>   10 LOAD_NAME                0 (foop)
     13 CALL_FUNCTION            0
     16 POP_TOP
     17 JUMP_ABSOLUTE           10
>>   20 POP_TOP
     21 POP_BLOCK
>>   22 LOAD_CONST               1 (None)
     25 RETURN_VALUE

x=compile('while True: foop()', '', 'exec')

dis.dis(x)

          0 SETUP_LOOP              19 (to 22)
    >>    3 LOAD_NAME                0 (True)
          6 JUMP_IF_FALSE           11 (to 20)
          9 POP_TOP
         10 LOAD_NAME                1 (foop)
         13 CALL_FUNCTION            0
         16 POP_TOP
         17 JUMP_ABSOLUTE            3
    >>   20 POP_TOP
         21 POP_BLOCK
    >>   22 LOAD_CONST               0 (None)
         25 RETURN_VALUE

reference:

Beginning talk related to assigning to True and False:

some Aux Data:

PS: some number shows True/1:

[alex@lancelot test]$ timeit.py -c -s'import itertools as it' 'c=it.count()'
'while True:' '  if c.next()>99: break'
10000 loops, best of 3: 91 usec per loop

[alex@lancelot test]$ timeit.py -c -s'import itertools as it' 'c=it.count()'
'while 1:' '  if c.next()>99: break'
10000 loops, best of 3: 76 usec per loop
maazza
  • 7,016
  • 15
  • 63
  • 96
chao787
  • 1,760
  • 3
  • 18
  • 20