Weird expression result

[George Sakkis]

I'm probably missing something obvious but I can't put my finger on
it:

>>(3 in [3]) == True

True

>>3 in ([3] == True)

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: argument of type 'bool' is not iterable

>>3 in [3] == True

False

How/why does the last one evaluate to False ?

George

[Peter Otten]

George Sakkis wrote:

I'm probably missing something obvious but I can't put my finger on
it:

>>>(3 in [3]) == True

True

>>>3 in ([3] == True)

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: argument of type 'bool' is not iterable

>>>3 in [3] == True

False

How/why does the last one evaluate to False ?

George

This works just like a < b < c:

>>3 in [3] and [3] == True

False

Peter

[Dan Lenski]

On Mon, 18 Aug 2008 18:04:32 +0200, Peter Otten wrote:

This works just like a < b < c:

>>>3 in [3] and [3] == True

False

Peter

Interesting. I agree with the OP that it is confusing!

Does this expansion really get invoked every time there is an expression
of the form??

expr1 binary_op1 expr2 binary_op2 expr3 ...

Seemingly, the answer is yes:

>>3 in [3] in [[3],[4]] in [[[3],[4]],5] == [[[3],[2+2]],5]

True

How does this play with standard precedence rules?

Dan

[cokofreedom]

On Aug 18, 5:57 pm, George Sakkis <[e-mail]:

I'm probably missing something obvious but I can't put my finger on
it:

>(3 in [3]) == True

True

>3 in ([3] == True)

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: argument of type 'bool' is not iterable

>3 in [3] == True

False

How/why does the last one evaluate to False ?

George

>(3 in [3]) == True

The list holds an integer value of 3, you check if 3 is in that list,
that is true, you then check it your answer is true...

>3 in ([3] == True)

True and False are keywords now and do not correspond the way you
think. [3] == True or [3] == False will both answer False.

Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.

>>a = list()
a.append(3)
3 in a

True

>>if a:

.... print "yay"
....
yay

>>if a == True:

.... print "yay"
.... else:
.... print "nay"
....
nay

>3 in [3] == True

http://docs.python.org/ref[3/summary.html

>>3 in [3] == True

False

>>3 in [3] == False

False

However I come a bit stuck myself, since this should just tell you
that you cannot do a membership test on 3 being in a bool...but it
doesn't...It should be doing the [3] == True, returning false then
trying to see if 3 is in false...

[Peter Otten]

Dan Lenski wrote:

On Mon, 18 Aug 2008 18:04:32 +0200, Peter Otten wrote:

>This works just like a < b < c:

>>>>3 in [3] and [3] == True

False

Interesting. I agree with the OP that it is confusing!

Does this expansion really get invoked every time there is an expression
of the form??

expr1 binary_op1 expr2 binary_op2 expr3 ...

Seemingly, the answer is yes:

>>3 in [3] in [[3],[4]] in [[[3],[4]],5] == [[[3],[2+2]],5]

True

How does this play with standard precedence rules?

Simple, all comparisons have the same priority:

http://docs.python.org/ref/comparisons.html

Peter

[George Sakkis]

On Aug 18, 12:04 pm, Peter Otten <[e-mail]:

George Sakkis wrote:

I'm probably missing something obvious but I can't put my finger on
it:

>>(3 in [3]) == True

True

>>3 in ([3] == True)

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: argument of type 'bool' is not iterable

>>3 in [3] == True

False

How/why does the last one evaluate to False ?

George

This works just like a < b < c:

>3 in [3] and [3] == True

False

Peter

Argh, you're right! I think chaining makes sense only for comparison
operators, for anything else it's not obvious. That came up from a
real bug by the way, it's not made up.

George

[Fredrik Lundh]

co*********@gmail.com wrote:

>>>>3 in [3] == True

http://docs.python.org/ref[3/summary.html

that page is broken, as recently mentioned; "in", "not in", "is", and
"is not" are comparison operators too, chains in the same way as the
others. for details, see:

http://docs.python.org/ref/comparisons.html#comparisons

</F>

[Dan Lenski]

On Mon, 18 Aug 2008 18:27:53 +0200, Peter Otten wrote:

Dan Lenski wrote:

>How does this play with standard precedence rules?

Simple, all comparisons have the same priority:

http://docs.python.org/ref/comparisons.html

Peter

I see. So, since the comparison operators have lower precedence than
everything else... it won't affect any terms involving non-comparison
operators.

Dan