Some more clarifications.

pep-0285.txt

@@ -26,7 +26,9 @@ Rationale
 
     Most languages eventually grow a Boolean type; even C99 has one.
     It's useful to be able to tell from a function result that the
-    outcome has Boolean semantics.
+    outcome has Boolean semantics, and it helps with things like RPC
+    protocols that may prefer to encode Booleans differently from
+    integers.
 
 
 Specification
@@ -36,12 +38,10 @@ Specification
 
         class bool(int):
 
-            def __new__(cls, val=0, _create=0):
-                if _create:
-                    # This is nor part of the spec,
-                    # just a hack to bootstrap False and True
-                    return int.__new__(cls, not not val)
-                elif val:
+            def __new__(cls, val=0):
+                # This constructor doesn't return a new instance;
+                # it returns an existing instance
+                if val:
                     return True
                 else:
                     return False
@@ -78,13 +78,15 @@ Specification
 
             __rxor__ = __xor__
 
-
-        False = bool(0, _create=1)
-        True = bool(1, _create=1)
+        # Bootstrap truth values through sheer willpower
+        False = int.__new__(bool, 0)
+        True = int.__new__(bool, 1)
 
     The values False and True will be singletons, like None; the C
     implementation will not allow other instances of bool to be
-    created.
+    created.  At the C level, the existing globals Py_False and
+    Py_True will be identical to the built-in singletons False and
+    True.
 
     All built-in operations that are defined to return a Boolean
     result will be changed to return False or True instead of 0 or 1.
@@ -95,17 +97,26 @@ Specification
     isdigit(), islower(), isspace(), istitle(), isupper(), and
     startswith(), and the closed attribute of file objects.
 
+    Note that subclassing from int means that True+1 is valid and
+    equals 2, and so on.  This is important for backwards
+    compatibility: because comparisons and so on currently return
+    integer values, there's no way of telling what uses existing
+    applications make of these values.
+
 
 Issues
 
     Because the repr() or str() of a bool value is different from an
-    int value, some code (e.g. doctest-based unit tests) may fail.
-    How much of a backwards compatibility problem this will be, I
-    don't know.  If we find this is a real problem, we could add a
-    command-line option to make False and True aliases for 0 and 1 and
-    bool an alias for int.
+    int value, some code (e.g. doctest-based unit tests, and possibly
+    database code that relies on things like "%s" % truthvalue) may
+    fail.  How much of a backwards compatibility problem this will be,
+    I don't know.  If we find this is a real problem, we could add a
+    command-line option to change the repr() and str() of False and
+    True to be '0' and '1'; or we could make this the defined
+    behavior, but that would defeat some of the purpose (being able to
+    see that a printed result is intended to be a truth value).
+
 
-                                   
 Copyright
 
     This document has been placed in the public domain.