This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Wrong bytecode generated for 'in' operation
Type: Stage:
Components: Interpreter Core Versions:
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: amaury.forgeotdarc, benjamin.peterson, brett.cannon, georg.brandl, isoschiz, ncoghlan, pconnell
Priority: normal Keywords:

Created on 2013-06-14 08:42 by pconnell, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (3)
msg191108 - (view) Author: Phil Connell (pconnell) * Date: 2013-06-14 08:42
The following two expressions should have the same value:

Python 3.4.0a0 (default:fae92309c3be, Jun 14 2013, 09:29:54) 
[GCC 4.8.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 1 in [2] == False
False
>>> (1 in [2]) == False
True


It looks like this is a compiler issue - there shouldn't be a jump if the 'in' expression is false:

>>> dis.dis("1 in [2] == False")
  1           0 LOAD_CONST               0 (1)
              3 LOAD_CONST               1 (2)
              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               2 (False)
             20 COMPARE_OP               2 (==)
             23 RETURN_VALUE        
        >>   24 ROT_TWO             
             25 POP_TOP             
             26 RETURN_VALUE        
>>>
msg191112 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2013-06-14 09:31
This is one case of chained comparisons:
http://docs.python.org/3/reference/expressions.html#not-in

"x <= y <= z" is equivalent to "(x <= y) and (y <= z)"
"x in y == z" is equivalent to "(x in y) and (y == z)"

There is a jump if the 'in' expression is false, because 'and' should short-circuit the second comparison.
msg191134 - (view) Author: Phil Connell (pconnell) * Date: 2013-06-14 14:59
Thanks Amaury. That's quite surprising, but I wouldn't advocate changing such long standing behaviour.

I'm closing the issue.
History
Date User Action Args
2022-04-11 14:57:46adminsetgithub: 62408
2013-06-14 14:59:31pconnellsetstatus: pending -> closed

messages: + msg191134
2013-06-14 09:31:13amaury.forgeotdarcsetstatus: open -> pending

nosy: + amaury.forgeotdarc
messages: + msg191112

resolution: not a bug
2013-06-14 08:42:34pconnellcreate