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

our bool is not very 'pure').
This commit is contained in:
Guido van Rossum 2002-03-10 04:46:49 +00:00
parent d38b6f17e3
commit 03691d24b9
1 changed files with 39 additions and 17 deletions

View File

@ -15,11 +15,11 @@ Abstract
This PEP proposes the introduction of a new built-in type, bool, This PEP proposes the introduction of a new built-in type, bool,
with two constants, False and True. The bool type would be a with two constants, False and True. The bool type would be a
straightforward subtype (in C) of the int type, and the values 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 and True would behave like 0 and 1 in most respects (for
False==0 and True==1 would be true) except repr() and str(). All example, False==0 and True==1 would be true) except repr() and
built-in operations that conceptually return a Boolean result will str(). All built-in operations that conceptually return a Boolean
be changed to return False or True instead of 0 or 1; for example, result will be changed to return False or True instead of 0 or 1;
comparisons and the "not" operator. for example, comparisons and the "not" operator.
Rationale Rationale
@ -37,7 +37,7 @@ Rationale
as "true" or "false"? Adding a standard bool type to the language as "true" or "false"? Adding a standard bool type to the language
resolves those issues. 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 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 create a solution, it would be
easier if the language offered a standard Boolean type. 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 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. result will be changed to return False or True instead of 0 or 1.
In particular, this affects comparisons (<, <=, ==, !=, >, >=, is, In particular, this affects comparisons (<, <=, ==, !=, >, >=, is,
is not, in, not it), the unary operator 'not', and built-in is not, in, not it), the unary operator 'not', the built-in
functions like callable(), hasattr(), isinstance() and functions callable(), hasattr(), isinstance() and issubclass(),
issubclass(), the dict method has_key(), string methods the dict method has_key(), the string and unicode methods
endswith(), isalnum(), isalpha(), isdigit(), islower(), isspace(), endswith(), isalnum(), isalpha(), isdigit(), islower(), isspace(),
istitle(), isupper(), and startswith(), and the closed attribute istitle(), isupper(), and startswith(), the unicode methods
of file objects. isdecimal() and isnumeric(), and the closed attribute of file
objects.
Note that subclassing from int means that True+1 is valid and Note that subclassing from int means that True+1 is valid and
equals 2, and so on. This is important for backwards equals 2, and so on. This is important for backwards
@ -150,15 +151,36 @@ Specification
applications make of these values. 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 Issues
Because the repr() or str() of a bool value is different from an 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 int value, some code (for example doctest-based unit tests, and
database code that relies on things like "%s" % truthvalue) may possibly database code that relies on things like "%s" % truth)
fail. How much of a backwards compatibility problem this will be, may fail. How much of a backwards compatibility problem this will
I don't know. If we this turns out to be a real problem, we could be, I don't know. If we this turns out to be a real problem, we
changes the rules so that str() of a bool returns "0" or "1", could changes the rules so that str() of a bool returns "0" or
while repr() of a bool still returns "False" or "True". "1", while repr() of a bool still returns "False" or "True".
Other languages (C99, C++, Java) name the constants "false" and Other languages (C99, C++, Java) name the constants "false" and
"true", in all lowercase. In Python, I prefer to stick with the "true", in all lowercase. In Python, I prefer to stick with the