Tell me the truth

[francois.petitjean]

In the python-ideas mailing list
http://mail.python.org/pipermail/python-ideas/2007-March/thread.html there
was a discussion about the fact that python has opeartors 'and', 'or' and
'not' (keywords of the language) but 'bool' is a type. Naturally we have
(not not x) == bool(x) # always True
If I take into account the fact that 'True' and 'False' are singletons
(guaranteed ?) :
(not not x) is bool(x) # should be always True.
.... return (not not x) is bool(x)
....True

ok(11) is True
True
Interesting.... Let's make another function:.... return (not not x) is bool(x) is True
....True

To see if the problem comes from using the a is b is True form, let's try.... return (not not x) is bool(x) == True
....False

After much head scrating and experimenting with dis.dis() I have found that
chaining comparisons (with is or ==) a == b == c in Python is never a good
idea. It is interpreted as
( a == b ) and ( b == c)
Such a magic is fine when we write:
if 0.0 <= x < 1.0:
but it renders the outcome of if a == b == c: somewhat confusing. In the
reference documentation the sentences """Comparisons can be chained
arbitrarily, e.g., x < y <= z is equivalent to x < y and y <= z, except
that y is evaluated only once (but in both cases z is not evaluated at all
when x < y is found to be false). """ should be followed by a warning about
chaining '==' or similar operators.

Regards

PS. Sorry for bad english.


NOTICE: This message contains information which is confidential and the
copyright of our company or a third party. If you are not the intended
recipient of this message please delete it and destroy all copies. If
you
are the intended recipient of this message you should not disclose or
distribute this message to third parties without the consent of our
company. Our company does not represent, warrant and/or guarantee that
the integrity of this message has been maintained nor that the
communication is free of virus, interception or interference. The
liability of our company is limited by our General Conditions of
Services.
Nota : Ce message contient des informations confidentielles propriété de
notre société et/ou d'un tiers. Si vous n'êtes pas parmi les
destinataires désignés de ce message, merci de l'effacer ainsi que
toutes ses copies. Si vous êtes parmi les destinataires désignés de ce
message, prière de ne pas le divulguer ni de le transmettre à des tiers
sans l'accord de notre société. Notre société ne peut garantir que
l'intégrité de ce message a été préservée ni que la présente
communication est sans virus, interception ou interférence. La
responsabilité de notre société est limitée par nos Conditions Générales
de Services.

 

[Duncan Booth]

After much head scrating and experimenting with dis.dis() I have found
that chaining comparisons (with is or ==) a == b == c in Python is
never a good idea. It is interpreted as
( a == b ) and ( b == c)
Such a magic is fine when we write:
if 0.0 <= x < 1.0:
but it renders the outcome of if a == b == c: somewhat confusing.

I don't understand why it is confusing. What other meaning would you
expect?

 

[Erik Johnson]

I don't understand why it is confusing. What other meaning would you
expect?

I can see how one might get themselves confused. I think it simply boils
down to thinking that

A == B == C is shorthand for: (A == B) == C

It's not. You're asserting that A is equivalent to B and B is equivalent to
C, NOT that the value of comparing A to B is equivalent to C:
False

If what you want is the second form, a pair of parenthesis forcing order of
evaluation will give it to you.
True


-ej