# Boolean confusion

Discussion in 'Python' started by Frantisek Fuka, Oct 31, 2003.

1. ### Frantisek FukaGuest

Can anyone please explain why these two give different results in Python
2.3?

>>> 'a' in 'abc' == 1

False
>>> ('a' in 'abc') == 1

True

I know it's not a good idea to compare boolean with Integer but that's
not the answer to my question.

--
Frantisek Fuka
(yes, that IS my real name)
(and it's pronounced "Fran-tjee-shek Foo-kah")
----------------------------------------------------
My E-mail:
My Homepage: http://www.fuxoft.cz
My ICQ: 2745855

Frantisek Fuka, Oct 31, 2003

2. ### Peter HansenGuest

Frantisek Fuka wrote:
>
> Can anyone please explain why these two give different results in Python
> 2.3?
>
> >>> 'a' in 'abc' == 1

> False
> >>> ('a' in 'abc') == 1

> True
>
> I know it's not a good idea to compare boolean with Integer but that's
> not the answer to my question.

Hmm....

>>> dis.dis(lambda : 'a' in 'abc' == 1)

1 0 LOAD_CONST 1 ('a')
3 LOAD_CONST 2 ('abc')
6 DUP_TOP
7 ROT_THREE
8 COMPARE_OP 6 (in)
11 JUMP_IF_FALSE 10 (to 24)
14 POP_TOP
15 LOAD_CONST 3 (1)
18 COMPARE_OP 2 (==)
21 JUMP_FORWARD 2 (to 26)
>> 24 ROT_TWO

25 POP_TOP
>> 26 RETURN_VALUE
>>> dis.dis(lambda : ('a' in 'abc') == 1)

1 0 LOAD_CONST 1 ('a')
3 LOAD_CONST 2 ('abc')
6 COMPARE_OP 6 (in)
9 LOAD_CONST 3 (1)
12 COMPARE_OP 2 (==)
15 RETURN_VALUE

Judging by the "odd" (unexpected) code in the first example,
"A in B == C" is actually doing operator chaining, in a manner
similar to "A < B < C". Since 'a' is in 'abc' but 'abc' is
not equal to 1, the chained test fails.

I can't comment further on the validity of such a thing, but
there you have it.

-Peter

Peter Hansen, Oct 31, 2003

3. ### John RothGuest

"Frantisek Fuka" <> wrote in message
news:bnua52\$tnv\$...
> Can anyone please explain why these two give different results in Python
> 2.3?
>
> >>> 'a' in 'abc' == 1

> False
> >>> ('a' in 'abc') == 1

> True
>
> I know it's not a good idea to compare boolean with Integer but that's
> not the answer to my question.

According to the operator precedence table given in the
Python Reference Manual, section 5.14 (2.2.3 version)
the "==" operator has higher precidence (that is, it will
be evaluated first) than the "in" operator. The table is,
unfortunately, upside down from my perspective, but
a close examination of the explanation shows what is
happening.

In other words, your first expression is equivalent
to:

"a" in ("abc" == 1)

John Roth
>
> --
> Frantisek Fuka
> (yes, that IS my real name)
> (and it's pronounced "Fran-tjee-shek Foo-kah")
> ----------------------------------------------------
> My E-mail:
> My Homepage: http://www.fuxoft.cz
> My ICQ: 2745855
>

John Roth, Oct 31, 2003
4. ### Frantisek FukaGuest

John Roth wrote:

> "Frantisek Fuka" <> wrote in message
> news:bnua52\$tnv\$...
>
>>Can anyone please explain why these two give different results in Python
>>2.3?
>>
>> >>> 'a' in 'abc' == 1

>>False
>> >>> ('a' in 'abc') == 1

>>True
>>
>>I know it's not a good idea to compare boolean with Integer but that's
>>not the answer to my question.

>
>
> According to the operator precedence table given in the
> Python Reference Manual, section 5.14 (2.2.3 version)
> the "==" operator has higher precidence (that is, it will
> be evaluated first) than the "in" operator. The table is,
> unfortunately, upside down from my perspective, but
> a close examination of the explanation shows what is
> happening.
>
> In other words, your first expression is equivalent
> to:
>
> "a" in ("abc" == 1)

No, it is not, because the original expression produces "False" while
your expression produces "TypeError: iterable argument required".

--
Frantisek Fuka
(yes, that IS my real name)
(and it's pronounced "Fran-tjee-shek Foo-kah")
----------------------------------------------------
My E-mail:
My Homepage: http://www.fuxoft.cz
My ICQ: 2745855

Frantisek Fuka, Oct 31, 2003
5. ### Alex MartelliGuest

John Roth wrote:
...
>> >>> 'a' in 'abc' == 1

>> False

...
> In other words, your first expression is equivalent
> to:
>
> "a" in ("abc" == 1)

Nope: that would raise an exception rather than returning
False (try it!).

What's happening is *chaining* of relationals, just like
when you write e.g. a < b <= c. In such cases the effect
is line (a < b) and (b <= c) except that b is only evaluated
once. Similarly, the first expression above is equivalent
to
('a' in 'abc') and ('abc' == 1)

Alex

Alex Martelli, Oct 31, 2003
6. ### John RothGuest

"Alex Martelli" <> wrote in message
news%yob.389675\$...
> John Roth wrote:
> ...
> >> >>> 'a' in 'abc' == 1
> >> False

> ...
> > In other words, your first expression is equivalent
> > to:
> >
> > "a" in ("abc" == 1)

>
> Nope: that would raise an exception rather than returning
> False (try it!).
>
> What's happening is *chaining* of relationals, just like
> when you write e.g. a < b <= c. In such cases the effect
> is line (a < b) and (b <= c) except that b is only evaluated
> once. Similarly, the first expression above is equivalent
> to
> ('a' in 'abc') and ('abc' == 1)

You're right. Section 5.9 says this, and directly contradicts
section 5.14 as well. 5.14 shows "in" as having a lower
priority than "==", while the verbiage n 5.9 says they
have the same priority.

One or the other should be corrected.

John Roth
>
>
> Alex
>

John Roth, Oct 31, 2003
7. ### Alex MartelliGuest

John Roth wrote:
...
> You're right. Section 5.9 says this, and directly contradicts
> section 5.14 as well. 5.14 shows "in" as having a lower
> priority than "==", while the verbiage n 5.9 says they
> have the same priority.
>
> One or the other should be corrected.

Can you please post this as a docs bug to sourceforge? Thanks!

Alex

Alex Martelli, Oct 31, 2003
8. ### John RothGuest

"Alex Martelli" <> wrote in message
news:q%zob.75527\$...
> John Roth wrote:
> ...
> > You're right. Section 5.9 says this, and directly contradicts
> > section 5.14 as well. 5.14 shows "in" as having a lower
> > priority than "==", while the verbiage n 5.9 says they
> > have the same priority.
> >
> > One or the other should be corrected.

>
> Can you please post this as a docs bug to sourceforge? Thanks!

Done for 2.2.3. Also noted that it's probably still a problem
with 2.3.2, but I haven't checked it out.

John Roth
>
>
> Alex
>

John Roth, Oct 31, 2003