By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
439,932 Members | 1,944 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 439,932 IT Pros & Developers. It's quick & easy.

Boolean confusion

P: n/a
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: fu**@fuxoft.cz
My Homepage: http://www.fuxoft.cz
My ICQ: 2745855

Jul 18 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
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
Jul 18 '05 #2

P: n/a

"Frantisek Fuka" <fu**@fuxoft.cz> wrote in message
news:bn**********@ns.felk.cvut.cz...
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: fu**@fuxoft.cz
My Homepage: http://www.fuxoft.cz
My ICQ: 2745855

Jul 18 '05 #3

P: n/a
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

Jul 18 '05 #4

P: n/a
John Roth wrote:
"Frantisek Fuka" <fu**@fuxoft.cz> wrote in message
news:bn**********@ns.felk.cvut.cz...
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: fu**@fuxoft.cz
My Homepage: http://www.fuxoft.cz
My ICQ: 2745855

Jul 18 '05 #5

P: n/a

"Alex Martelli" <al***@aleax.it> wrote in message
news:p%***********************@news2.tin.it...
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

Jul 18 '05 #6

P: n/a
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

Jul 18 '05 #7

P: n/a

"Alex Martelli" <al***@aleax.it> wrote in message
news:q%********************@news1.tin.it...
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

Jul 18 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.