More rationale and issues.

pep-0285.txt

@@ -25,10 +25,55 @@ Abstract
 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, and it helps with things like RPC
-    protocols that may prefer to encode Booleans differently from
-    integers.
+
+    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
+    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",
+    "False", "F" or even "f"?  And should false be the value zero or
+    None, or perhaps a truth value of a different type that will print
+    as "true" or "false"?  Adding a standard bool type to the language
+    resolves those issues.
+
+    Some external libraries (e.g. 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
+    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:
+
+        >>> a = 13
+        >>> b = 12
+        >>> a > b
+        1
+        >>>
+
+    If this was:
+
+        >>> a > b
+        True
+        >>>
+
+    it would require one millisecond less thinking each time a 0 or 1
+    was printed.
+
+    There's also the issue (which I've seen puzzling even experienced
+    Pythonistas who had been away from the language for a while) that if
+    you see:
+
+        >>> cmp(a, b)
+        1
+        >>> cmp(a, a)
+        0
+        >>> 
+
+    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.
 
 
 Specification
@@ -110,11 +155,17 @@ Issues
     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).
+    I don't know.  If we this turns out to be a real problem, we could
+    changes the rules so that str() of a bool returns "0" or "1",
+    while repr() of a bool still returns "False" or "True".
+
+    Other languages (C99, C++, Java) name the constants "false" and
+    "true", in all lowercase.  In Python, I prefer to stick with the
+    example set by the existing built-in constants, which all use
+    CapitalizedWords: None, Ellipsis, NotImplemented (as well as all
+    built-in exceptions).  Python's built-in module uses all lowercase
+    for functions and types only.  But I'm willing to consider the
+    lowercase alternatives if enough people think it looks better.
 
 
 Copyright