[Python-checkins] CVS: python/nondist/peps pep-0285.txt,1.6,1.7

[Guido van Rossum]

Update of /cvsroot/python/python/nondist/peps
In directory usw-pr-cvs1:/tmp/cvs-serv4767

Modified Files:
	pep-0285.txt 
Log Message:
Some clarifications.  Add section on compatibility (and why this means
our bool is not very 'pure').


Index: pep-0285.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0285.txt,v
retrieving revision 1.6
retrieving revision 1.7
diff -C2 -d -r1.6 -r1.7
*** pep-0285.txt	10 Mar 2002 03:36:14 -0000	1.6
--- pep-0285.txt	10 Mar 2002 04:46:49 -0000	1.7
***************
*** 16,24 ****
      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.
  
  
--- 16,24 ----
      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 (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.
  
  
***************
*** 38,42 ****
      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
--- 38,42 ----
      resolves those issues.
  
!     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
***************
*** 137,146 ****
      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
      endswith(), isalnum(), isalpha(), 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
--- 137,147 ----
      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
!     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
!     objects.
  
      Note that subclassing from int means that True+1 is valid and
***************
*** 151,163 ****
  
  
  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".
  
      Other languages (C99, C++, Java) name the constants "false" and
--- 152,185 ----
  
  
+ 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 (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