Some clarifications. Add section on compatibility (and why this means

our bool is not very 'pure').

pep-0285.txt

@@ -15,11 +15,11 @@ Abstract
     This PEP proposes the introduction of a new built-in type, bool,
     with two constants, False and True.  The bool type would be a
     straightforward subtype (in C) of the int type, and the values
-    False and True would behave like 0 and 1 in most respects (e.g.
-    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.
+    False and True would behave like 0 and 1 in most respects (for
+    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.
 
 
 Rationale
@@ -37,7 +37,7 @@ Rationale
     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
+    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
     easier if the language offered a standard Boolean type.
@@ -136,12 +136,13 @@ Specification
     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', and built-in
-    functions like callable(), hasattr(), isinstance() and
-    issubclass(), the dict method has_key(), string methods
+    is not, in, not it), 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(), and the closed attribute
-    of file objects.
+    istitle(), isupper(), and startswith(), the unicode methods
+    isdecimal() and isnumeric(), 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
@@ -150,15 +151,36 @@ Specification
     applications make of these values.
 
 
+Compatibility
+
+    Because of backwards compatibility, the bool type lacks many
+    properties that some would like to see.  For example, arithmetic
+    operations with one or two bool arguments is allowed, treating
+    False as 0 and True as 1.  Also, a bool may be used as a sequence
+    index.
+
+    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.
+
+    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"
+    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)".
+
+
 Issues
 
     Because the repr() or str() of a bool value is different from an
-    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 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".
+    int value, some code (for example doctest-based unit tests, and
+    possibly database code that relies on things like "%s" % truth)
+    may fail.  How much of a backwards compatibility problem this will
+    be, 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