Slightly updated; corrected typos; added one extra argument.

pep-0285.txt

@@ -7,7 +7,7 @@ Status: Draft
 Type: Standards Track
 Created: 8-Mar-2002
 Python-Version: 2.3
-Post-History: 8-Mar-2002
+Post-History: 8-Mar-2002, 30-Mar-2002
 
 
 Abstract
@@ -19,16 +19,18 @@ Abstract
     example, False==0 and True==1 would be true) except repr() and
     str().  All built-in operations that conceptually return a Boolean
     result will be changed to return False or True instead of 0 or 1;
-    for example, comparisons and the "not" operator.
+    for example, comparisons, the "not" operator, and predicates like
+    isinstance().
 
 
 Rationale
 
-    Most languages eventually grow a Boolean type; even C99 has one.
+    Most languages eventually grow a Boolean type; even C99 (the new
+    and improved C standard, not yet widely adopted) has one.
 
     Many programmers apparently feel the need for a Boolean type; most
     Python documentation contains a bit of an apology for the absence
-    of a Boolean type.  I've seen lots of module that defined
+    of a Boolean type.  I've seen lots of modules that defined
     constants "False=0" and "True=1" (or similar) at the top and used
     those.  The problem with this is that everybody does it
     differently.  For example, should you use "FALSE", "false",
@@ -39,12 +41,22 @@ Rationale
 
     Some external libraries (like databases and RPC packages) need to
     be able to distinguish between Boolean and integral values, and
-    while it's usually possible to create a solution, it would be
+    while it's usually possible to craft a solution, it would be
     easier if the language offered a standard Boolean type.
 
-    And here's an argument derived from teaching Python.  When showing
-    people comparison operators etc. in the interactive shell, I think
-    this is a bit ugly:
+    The standard bool type can also serve as a way to force a value to
+    be interpreted as a Boolean, which can be used to normalize
+    Boolean values.  Writing bool(x) is much clearer than "not not x"
+    and much more concise than
+
+        if x:
+            return 1
+        else:
+            return 0
+
+    Here are some arguments derived from teaching Python.  When
+    showing people comparison operators etc. in the interactive shell,
+    I think this is a bit ugly:
 
         >>> a = 13
         >>> b = 12
@@ -73,7 +85,8 @@ Rationale
 
     you might be tempted to believe that cmp() also returned a truth
     value.  If ints are not (normally) used for Booleans results, this
-    would stand out much more clearly as something completely different.
+    would stand out much more clearly as something completely
+    different.
 
 
 Specification
@@ -84,8 +97,7 @@ Specification
         class bool(int):
 
             def __new__(cls, val=0):
-                # This constructor doesn't return a new instance;
-                # it returns an existing instance
+                # This constructor always returns an existing instance
                 if val:
                     return True
                 else:
@@ -130,18 +142,17 @@ Specification
     The values False and True will be singletons, like None; the C
     implementation will not allow other instances of bool to be
     created.  At the C level, the existing globals Py_False and
-    Py_True will be identical to the built-in singletons False and
-    True.
+    Py_True will be appropriated to refer to 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.
     In particular, this affects comparisons (<, <=, ==, !=, >, >=, is,
-    is not, in, not it), the unary operator 'not', the built-in
+    is not, in, not in), the unary operator 'not', the built-in
     functions callable(), hasattr(), isinstance() and issubclass(),
     the dict method has_key(), the string and unicode methods
     endswith(), isalnum(), isalpha(), isdigit(), islower(), isspace(),
     istitle(), isupper(), and startswith(), the unicode methods
-    isdecimal() and isnumeric(), and the closed attribute of file
+    isdecimal() and isnumeric(), and the 'closed' attribute of file
     objects.
 
     Note that subclassing from int means that True+1 is valid and
@@ -161,15 +172,17 @@ Compatibility
 
     I don't see this as a problem, and I don't want evolve the
     language in this direction either; I don't believe that a stricter
-    interpretation of "Booleanness" makes the language much clearer.
+    interpretation of "Booleanness" makes the language any clearer.
 
     Another consequence of the compatibility requirement is that the
     expression "True and 6" has the value 6, and similarly the
-    expression "False or 0" has the value 0.  The "and" and "or"
+    expression "False or None" has the value None.  The "and" and "or"
     operators are usefully defined to return the first argument that
-    determines the outcome.  Of course, if both arguments are bools,
-    the outcome is always a bool.  It can also easily be coerced into
-    being a bool by writing for example "bool(x and y)".
+    determines the outcome, and this won't change; in particular, they
+    don't force the outcome to be a bool.  Of course, if both
+    arguments are bools, the outcome is always a bool.  It can also
+    easily be coerced into being a bool by writing for example
+    "bool(x and y)".
 
 
 Issues