homepage

So I found this while using == as xnor, here's a summary of the issue:
>>> "h" in ["h"] == True
False
>>> ("h" in ["h"]) == True
True
>>> "h" in (["h"] == True)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: argument of type 'bool' is not iterable
Now obviously #3 should error but I would expect #1 and #2 to be the same. I checked it out with dis (in Py 3.4) and it seems like a bug. In detail:
#2's is very clean, exactly what I would expect:
>>> dis.dis('("h" in ["h"]) == True')
 1 0 LOAD_CONST 0 ('h')
 3 LOAD_CONST 2 (('h',))
 6 COMPARE_OP 6 (in)
 9 LOAD_CONST 1 (True)
 12 COMPARE_OP 2 (==)
 15 RETURN_VALUE
#1's, however, looks like a mess:
>>> dis.dis('"h" in ["h"] == True')
 1 0 LOAD_CONST 0 ('h')
 3 LOAD_CONST 0 ('h')
 6 BUILD_LIST 1
 9 DUP_TOP
 10 ROT_THREE
 11 COMPARE_OP 6 (in)
 14 JUMP_IF_FALSE_OR_POP 24
 17 LOAD_CONST 1 (True)
 20 COMPARE_OP 2 (==)
 23 RETURN_VALUE
 >> 24 ROT_TWO
 25 POP_TOP
 26 RETURN_VALUE
I had to write out the stack to understand this:
1. ['h']
2. ['h', 'h']
3. ['h', ['h']]
4. ['h', ['h'], ['h']]
5. [['h'], 'h', ['h']]
6. [['h'], True] # True = result of in operation
7. [['h']]
8. [['h'], True] # True = =='s right-hand value
9. [False] # False = result of == operation
Therefore the way to actually get true in the first case is:
>>> "h" in ["h"] == ["h"]
True
I won't pretend to know how simple it is in Python's architecture but I imagine it's just setting a higher precedence for "in" than ==?
Not a huge deal, it's workaroundable, just awkward that there wasn't really any indication it was failing so it took a bit to debug.

As far as I understand, this is treated as "x < y < z" or "x == y == z":
>>> import ast
>>> ast.dump(ast.parse("1 < 2 < 3"))
'Module(body=[Expr(value=Compare(left=Num(n=1), ops=[Lt(), Lt()], comparators=[Num(n=2), Num(n=3)]))])
>>> ast.dump(ast.parse("1 == 2 == 3"))
'Module(body=[Expr(value=Compare(left=Num(n=1), ops=[Eq(), Eq()], comparators=[Num(n=2), Num(n=3)]))])'
>>> ast.dump(ast.parse("1 in 2 == 3"))
'Module(body=[Expr(value=Compare(left=Num(n=1), ops=[In(), Eq()], comparators=[Num(n=2), Num(n=3)]))])'
The following code is also valid and works as expected:
>>> 1 in [1] in [[1]]
True
>>> 2 not in [1] in [[1]]
True
Your example yields an unexpected result, but I'm not sure if and how it can be fixed.

https://docs.python.org/3/reference/expressions.html#comparisons says that "a op1 b op2 c ... y opN z is equivalent to a op1 b and b op2 c and ... y opN z" and this explains the "unexpected" result:
>>> 1 in [1] == True
False
>>> 1 in [1] and [1] == True
False
"in" and "not in" are also listed among the comparison operators, so I think this behavior is expected and by design. I don't think there's anything that needs to be fixed here.