Boolean confusion

[Frantisek Fuka]

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

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

 

[Peter Hansen]

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

True

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

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) 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

 

[John Roth]

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

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]

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".

 

[Alex Martelli]

John Roth wrote:
...

...
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

 

[John Roth]

John Roth wrote:
...

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 Martelli]

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

 

[John Roth]

John Roth wrote:
...

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