Update of /cvsroot/python/python/nondist/peps
In directory usw-pr-cvs1:/tmp/cvs-serv26121
Modified Files:
pep-0285.txt
Log Message:
Slightly updated; corrected typos; added one extra argument.
Index: pep-0285.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0285.txt,v
retrieving revision 1.8
retrieving revision 1.9
diff -C2 -d -r1.8 -r1.9
*** pep-0285.txt 10 Mar 2002 05:47:36 -0000 1.8
--- pep-0285.txt 30 Mar 2002 05:02:42 -0000 1.9
***************
*** 8,12 ****
Created: 8-Mar-2002
Python-Version: 2.3
! Post-History: 8-Mar-2002
--- 8,12 ----
Created: 8-Mar-2002
Python-Version: 2.3
! Post-History: 8-Mar-2002, 30-Mar-2002
***************
*** 20,33 ****
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
! Most languages eventually grow a Boolean type; even C99 has one.
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
--- 20,35 ----
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, the "not" operator, and predicates like
! isinstance().
Rationale
! Most languages eventually grow a Boolean type; even C99 (the new
! and improved C standard, not yet widely adopted) has one.
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 modules 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
***************
*** 40,49 ****
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.
! 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
--- 42,61 ----
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 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:
! return 1
! else:
! return 0
!
! Here are some arguments derived from teaching Python. When
! showing people comparison operators etc. in the interactive shell,
! I think this is a bit ugly:
>>> a = 13
***************
*** 74,78 ****
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.
--- 86,91 ----
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.
***************
*** 85,90 ****
def __new__(cls, val=0):
! # This constructor doesn't return a new instance;
! # it returns an existing instance
if val:
return True
--- 98,102 ----
def __new__(cls, val=0):
! # This constructor always returns an existing instance
if val:
return True
***************
*** 131,146 ****
implementation will not allow other instances of bool to be
created. At the C level, the existing globals Py_False and
! Py_True will be identical to the built-in singletons False and
! True.
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', 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.
--- 143,157 ----
implementation will not allow other instances of bool to be
created. At the C level, the existing globals Py_False and
! Py_True will be appropriated to refer to False and True.
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 in), 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.
***************
*** 162,174 ****
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)".
--- 173,187 ----
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 any clearer.
Another consequence of the compatibility requirement is that the
expression "True and 6" has the value 6, and similarly the
! expression "False or None" has the value None. The "and" and "or"
operators are usefully defined to return the first argument that
! determines the outcome, and this won't change; in particular, they
! don't force the outcome to be a bool. 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)".
In directory usw-pr-cvs1:/tmp/cvs-serv26121
Modified Files:
pep-0285.txt
Log Message:
Slightly updated; corrected typos; added one extra argument.
Index: pep-0285.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0285.txt,v
retrieving revision 1.8
retrieving revision 1.9
diff -C2 -d -r1.8 -r1.9
*** pep-0285.txt 10 Mar 2002 05:47:36 -0000 1.8
--- pep-0285.txt 30 Mar 2002 05:02:42 -0000 1.9
***************
*** 8,12 ****
Created: 8-Mar-2002
Python-Version: 2.3
! Post-History: 8-Mar-2002
--- 8,12 ----
Created: 8-Mar-2002
Python-Version: 2.3
! Post-History: 8-Mar-2002, 30-Mar-2002
***************
*** 20,33 ****
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
! Most languages eventually grow a Boolean type; even C99 has one.
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
--- 20,35 ----
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, the "not" operator, and predicates like
! isinstance().
Rationale
! Most languages eventually grow a Boolean type; even C99 (the new
! and improved C standard, not yet widely adopted) has one.
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 modules 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
***************
*** 40,49 ****
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.
! 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
--- 42,61 ----
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 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:
! return 1
! else:
! return 0
!
! Here are some arguments derived from teaching Python. When
! showing people comparison operators etc. in the interactive shell,
! I think this is a bit ugly:
>>> a = 13
***************
*** 74,78 ****
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.
--- 86,91 ----
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.
***************
*** 85,90 ****
def __new__(cls, val=0):
! # This constructor doesn't return a new instance;
! # it returns an existing instance
if val:
return True
--- 98,102 ----
def __new__(cls, val=0):
! # This constructor always returns an existing instance
if val:
return True
***************
*** 131,146 ****
implementation will not allow other instances of bool to be
created. At the C level, the existing globals Py_False and
! Py_True will be identical to the built-in singletons False and
! True.
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', 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.
--- 143,157 ----
implementation will not allow other instances of bool to be
created. At the C level, the existing globals Py_False and
! Py_True will be appropriated to refer to False and True.
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 in), 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.
***************
*** 162,174 ****
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)".
--- 173,187 ----
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 any clearer.
Another consequence of the compatibility requirement is that the
expression "True and 6" has the value 6, and similarly the
! expression "False or None" has the value None. The "and" and "or"
operators are usefully defined to return the first argument that
! determines the outcome, and this won't change; in particular, they
! don't force the outcome to be a bool. 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)".