I wrote:
> > I think at least add something like this should be added
> > to the description in the PEP:
> > def __cmp__(self,other):
> > return int.__cmp__(self,bool(other))
Guido van Rossum wrote:
> Absolutely not. I want True == 2 to be False.
BTW, I am in favor of a standard boolean type. But I am
concerned about how it interacts with the conventions
for truth of an expression.
For example:
(1 == True) != (2 == True)
yet:
bool(1) == bool(2) == bool(1 and 2) == ... == True
and of course:
(1 != False) == (2 != False)
And how about:
my_list == True
versus:
bool(my_list)
Since boolean values are often computed, you may run into
subtle differences in behavior that would introduce bugs.
These would become apparent when you tried to mix code that
uses the truth conventions together with code that uses the
new boolean type. You may find that in many cases you will
have to resort to sprinkling bool()-casts/operator.truth()
everywhere.
I expect this would primarily affect compares. For example,
with the current definition it is already true that:
bool(my_list) == bool(my_list and True or False)
Using boolean values in algebraic expressions is not really
much of a problem unless you are relying on expressions to
be used in boolean context that may have values other than
0 or 1. In other words, this isn't a problem:
days_in_year = 365 + bool(leap_year)
But this would be (assuming leap_year_expected is a bool):
assert(leap_year == leap_year_expected)
if leap_year:
days_in_year = leap_year
else:
days_in_year = 365
So compares do raise issues. Promoting the other side of a
compare-with-boolean to a boolean is one way to maintain
some compatibility. You could also disallow the compare in
the first place.
I didn't want to suggest that, since it is a more drastic
change. Disallowing boolean promotions may eventually take
you down a route that disallows this:
if mylist:
in favor of this:
if bool(mylist):
If that's the way you want to head anyway, then that's fine
also. I think that (2 == True) == True can be justified, but
there are other ways to address the issue. Probably even
some that aren't as drastic. :-)
-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-
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4