[issue25484] Operator issue with "in" on same level and preceding ==

2015-10-26 Thread Sapphire Becker

New submission from Sapphire Becker:

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 "", line 1, in 
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_POP24
 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.

--
components: Interpreter Core
messages: 253478
nosy: Sapphire Becker
priority: normal
severity: normal
status: open
title: Operator issue with "in" on same level and preceding ==
type: behavior
versions: Python 2.7, Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25484] Operator issue with "in" on same level and preceding ==

2015-10-26 Thread Ezio Melotti

Ezio Melotti added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25484] Operator issue with "in" on same level and preceding ==

2015-10-26 Thread Ezio Melotti

Changes by Ezio Melotti :


--
nosy: +ezio.melotti
versions: +Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25484] Operator issue with "in" on same level and preceding ==

2015-10-26 Thread Ezio Melotti

Ezio Melotti added the comment:

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.

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com