[Python-Dev] Re: PEP 285: Adding a bool type (original) (raw)
Gerald S. Williams gsw@agere.com
Mon, 1 Apr 2002 08:55:13 -0500
- Previous message: [Python-Dev] Moving forward on the object memory API
- Next message: [Python-Dev] Moving forward on the object memory API
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Guido van Rossum wrote:
I offer the following PEP for review by the community. If it receives a favorable response, it will be implemented in Python 2.3.
I like almost all of it as written.
2) Should str(True) return "True" or "1": "1" might reduce backwards compatibility problems, but looks strange to me.
I also prefer "True". int(True) returns 1 if you need it.
3) Should the constants be called 'True' and 'False'
I prefer "True" here also (this is Python, not C).
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.
No need. It is only equivalence operations that cause problems.
It has been suggested that, in order to satisfy user expectations, for every x that is considered true in a Boolean context, the 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.
I (was at least one of the people who) brought this up.
Without getting tied up in the discussion about which should inherit from which: in boolean context, 6 == 7 and [] == None. This does not imply that they are equivalent elsewhere.
The problem is the equivalence test itself. It may be true that "if x == True:" is redundant, in which case you may want to disallow such comparisons. But performing an integer comparison will confuse perfectly rational people at least some of the time.
Consider that the main source of confusion won't come from comparisons to True, but comparisons to False. These two statements might look identical to the casual observer, but they really aren't:
if not expr:
if expr == False:
I think that is probably the best way to summarize my concern.
-Jerry
-O Gerald S. Williams, 22Y-103GA : mailto:gsw@agere.com O- -O AGERE SYSTEMS, 555 UNION BLVD : office:610-712-8661 O- -O ALLENTOWN, PA, USA 18109-3286 : mobile:908-672-7592 O-
- Previous message: [Python-Dev] Moving forward on the object memory API
- Next message: [Python-Dev] Moving forward on the object memory API
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]