[Python-checkins] CVS: python/nondist/peps pep-0285.txt,1.13,1.14
Guido van Rossum
gvanrossum@users.sourceforge.net
Sun, 31 Mar 2002 03:26:18 -0800
Update of /cvsroot/python/python/nondist/peps
In directory usw-pr-cvs1:/tmp/cvs-serv13437
Modified Files:
pep-0285.txt
Log Message:
Incorporated review feedback. Added Jython argument. Added mention
of standard library. Added clarification that "if <list>:" remains
as valid as ever. Minor rewordings all over, got rid of "e.g." again.
Index: pep-0285.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0285.txt,v
retrieving revision 1.13
retrieving revision 1.14
diff -C2 -d -r1.13 -r1.14
*** pep-0285.txt 30 Mar 2002 13:39:00 -0000 1.13
--- pep-0285.txt 31 Mar 2002 11:26:16 -0000 1.14
***************
*** 33,46 ****
1) Should this PEP be accepted at all.
2) Should str(True) return "True" or "1": "1" might reduce
backwards compatibility problems, but looks strange to me.
(repr(True) would always return "True".)
3) Should the constants be called 'True' and 'False'
(corresponding to None) or 'true' and 'false' (as in C++, Java
and C99).
Most other details of the proposal are pretty much forced by the
! backwards compatibility requirement; e.g. True == 1 and
True+1 == 2 must hold, else reams of existing code would break.
--- 33,61 ----
1) Should this PEP be accepted at all.
+ => The majority of reviewers so far are in favor, ranging from +0
+ (don't hate it) to 1 (yes please). Votes against are mixed:
+ some are against all change, some think it's not needed, some
+ think it will just add more confusion or complexity, some have
+ irrational fears about code breakage based on misunderstanding
+ the PEP (believing it adds reserved words, or believing it will
+ require you to write "if bool(x):" where previously "if x:"
+ worked; neither belief is true).
+
2) Should str(True) return "True" or "1": "1" might reduce
backwards compatibility problems, but looks strange to me.
(repr(True) would always return "True".)
+ => Most reviewers prefer str(True) == "True" (which may mean that
+ they don't appreciate the specific
+
3) Should the constants be called 'True' and 'False'
(corresponding to None) or 'true' and 'false' (as in C++, Java
and C99).
+ => There's no clear preference either way here, so I'll break the
+ tie by pronouncing False and True.
+
Most other details of the proposal are pretty much forced by the
! backwards compatibility requirement; for example, True == 1 and
True+1 == 2 must hold, else reams of existing code would break.
***************
*** 48,63 ****
4) Should we strive to eliminate non-Boolean operations on bools
! in the future, through suitable warnings, so that e.g. True+1
! would eventually (e.g. in Python 3000 be illegal). Personally,
! I think we shouldn't; 28+isleap(y) seems totally reasonable to
! me.
5) Should operator.truth(x) return an int or a bool. Tim Peters
believes it should return an int because it's been documented
as such. I think it should return a bool; most other standard
! predicates (e.g. issubtype()) have also been documented as
returning 0 or 1, and it's obvious that we want to change those
to return a bool.
Rationale
--- 63,118 ----
4) Should we strive to eliminate non-Boolean operations on bools
! in the future, through suitable warnings, so that for example
! True+1 would eventually (in Python 3000) be illegal.
! Personally, I think we shouldn't; 28+isleap(y) seems totally
! reasonable to me.
!
! => Most reviewers agree with me.
5) Should operator.truth(x) return an int or a bool. Tim Peters
believes it should return an int because it's been documented
as such. I think it should return a bool; most other standard
! predicates (like issubtype()) have also been documented as
returning 0 or 1, and it's obvious that we want to change those
to return a bool.
+ => Most reviewers agree with me. My take: operator.truth() exists
+ to force a Boolean context on its argument (it calls the C API
+ PyObject_IsTrue()). Whether the outcome is reported as int or
+ bool is secondary; if bool exists there's no reason not to use
+ it.
+
+ New issues brought up during the review:
+
+ 6) Should bool inherit from int?
+
+ => My take: in an ideal world, bool might be better implemented as
+ a separate integer type that knows how to perform mixed-mode
+ arithmetic. However, inheriting bool from int eases the
+ implementation enormously (in part since all C code that calls
+ PyInt_Check() will continue to work -- this returns true for
+ subclasses of int). Also, I believe in terms of
+ substitutability, this is right: code that requires an int can
+ be fed a bool and it will behave the same as 0 or 1. Code that
+ requires a bool may not work when it is given an int; for
+ example, 3 & 4 is 0, but both 3 and 4 are true when considered
+ as truth values.
+
+ 7) Should the name 'bool' be changed?
+
+ => Some reviewers argue for boolean instead of bool, because this
+ would be easier to understand (novices may have heard of
+ Boolean algebra but may not make the connection with bool) or
+ because they hate abbreviations. My take: Python uses
+ abbreviations judiciously (like 'def', 'int', 'dict') and I
+ don't think these are a burden to understanding.
+
+ One reviewer argues to make the name 'truth'. I find this an
+ unattractive name, and would actually prefer to reserve this
+ term (in documentation) for the more abstract concept of truth
+ values that already exists in Python. For example: "when a
+ container is interpreted as a truth value, an empty container
+ is considered false and a non-empty one is considered true."
+
Rationale
***************
*** 80,89 ****
be able to distinguish between Boolean and integral values, and
while it's usually possible to craft a solution, it would be
! easier if the language offered a standard Boolean type.
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:
--- 135,148 ----
be able to distinguish between Boolean and integral values, and
while it's usually possible to craft a solution, it would be
! easier if the language offered a standard Boolean type. This also
! applies to Jython: some Java classes have separately overloaded
! methods or constructors for int and boolean arguments. The bool
! type can be used to select the boolean variant.
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. When a Boolean value needs to be normalized to
! one of two values, bool(x) is much clearer than "not not x" and
! much more concise than
if x:
***************
*** 193,201 ****
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.
--- 252,280 ----
objects.
! Because bool inherits from int, 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.
!
! It is expected that over time, the standard library will be
! updated to use False and True when appropriate (but not to require
! a bool argument type where previous an int was allowed). This
! change should not pose additional problems and is not specified in
! detail by this PEP.
!
!
! Clarification
!
! This PEP does *not* change the fact that almost all object types
! can be used as truth values. For example, when used in an if
! statement, an empty list is false and a non-empty one is true;
! this does not change and there is no plan to ever change this.
!
! The only thing that changes is the preferred values to represent
! truth values when returned or assigned explicitly. Previously,
! these preferred truth values were 0 and 1; the PEP changes the
! preferred values to False and True, and changes built-in
! operations to return these preferred values.
***************
*** 245,254 ****
expression x == True should be true, and likewise if x is
considered false, x == False should be true. This is of course
! impossible; it would mean that e.g. 6 == True and 7 == True, from
! which one could infer 6 == 7. Similarly, [] == False == None
! would be true, and one could infer [] == None, which is not the
! case. I'm not sure where this suggestion came from; it was made
! several times during the first review period. For truth testing
! of a value, one should use "if", e.g. "if x: print 'Yes'", not
comparison to a truth value; "if x == True: print 'Yes'" is not
only wrong, it is also strangely redundant.
--- 324,333 ----
expression x == True should be true, and likewise if x is
considered false, x == False should be true. This is of course
! impossible; it would mean that for example 6 == True and 7 ==
! True, from which one could infer 6 == 7. Similarly, [] == False
! == None would be true, and one could infer [] == None, which is
! not the case. I'm not sure where this suggestion came from; it
! was made several times during the first review period. For truth
! testing, one should use "if", as in "if x: print 'Yes'", not
comparison to a truth value; "if x == True: print 'Yes'" is not
only wrong, it is also strangely redundant.