On 2009-01-24 19:07, Oktay Şafak wrote:
Robert Kern wrote:
On 2009-01-24 17:00, oktaysa...@superonline.com wrote:
Hi all,
I ran into a strange case.
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on win32
...
>>> -1 == True
False
>>> -1 == False
False
This works though:
>>> if -1:
print "OK"
OK
After some head scratching, I realized that:
- bool is a subclass of int and that True and False evaluates to 1 and
0, so -1 is equal to neither; and
- The if -1: statement probably works by treating -1 as bool(-1).
Yes.
Good.
But I can't help finding the former comparison behavior odd. I admit
that it is odd to write such code but when someone writes -1 == True,
the intention is clearly a boolean comparison, not a numerical value
comparison, isn't it?
Not to me. The rules of Python state that the object on the left hand
side is asked first how to compare the two values. Only if that fails
is the object on the right hand side asked how to compare the objects.
OK.
As far as I understand, to do this comparison, python is casting
(loosely speaking) True to its numerical value, rather than casting -1
to its boolean value.
Not really. No casting goes on at all.
Of course, I said loosely speaking.
bool is just one of the types that int.__eq__ knows how to handle
because bool is a subclass of int. Vice-versa, bool.__eq__ knows how
to handle ints, and it also does a numerical comparison; it never
casts to a boolean.
That's what I'm trying to say: it would be more meaningful if int.__eq__
did a boolean comparison when the other operand is a boolean. And
bool.__eq__ should as well do a boolean comparison when the other
operand is an integer (or even a number). The reason is that when
someone writes (-1 == True) he is clearly, definitely, absolutely asking
for a boolean comparison, not a numerical one. As I said before, this is
weird code; but using the True built-in for checking whether a number's
value is equal to 1 would be even weirder.
So don't do it. There really aren't many use cases for comparing with a boolean.
Just call bool() on the object.
So, my question is: wouldn't it make more sense to do just the opposite,
i.e. cast -1 to its boolean value and do a boolean comparison of the
operands, when one of the operands is True or False?
Or is this too fancy? What do you think?
I think that being explicit is better than being implicit.
Well, I agree that explicit is better than implicit: when one wants to
use the numerical values of True or False, he should make it explicit
and use int(True) or int(False), but one is never interested in a
boolean's numerical value (which is nonsense, IMHO). We never write
counter += True, for example.
Actually, I sum up booleans quite often.
If you want to cast an object to a boolean, use bool() on it.
Well, I can tell you in response that if you are interested in a
boolean's *integer* value, than make it explicit and use int(True).
The two positions are not symmetrical. Your position requires special-casing
equality testing; Python's position doesn't.
When
I write
assert i == True
I'm not trying to make sure that i is equal to one, I am trying to make
sure that it evaluates to True (of course True is redundant here but it
can make the code more readable). If I was interested in the former
case, it would be most natural to write assert i == 1 but I'm interested
in the latter and I think Python's treatment is not quite right here.
Then just do "assert i" or "assert bool(i)" and be done with it. There's no need
to do any comparisons at all.
> Making special rules when comparing with booleans makes it harder to
> treat True and False as first-class objects.
I don't see how fixing this makes harder to treat True and False as
first-class objects. If doing the right thing takes some special casing
then be it, but I don't think it's so.
True in ['something', False]
In your semantics, this would evaluate to True because ('something' == True) is
True.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
--
http://mail.python.org/mailman/listinfo/python-list
