for try else bug in 3.x

[rocky]

Works on 2.6 and 2.7, but not 3.x where the try-else gets compiled as try without an else clause.

That is this:

# Bug found in 2.7 test_itertools.py
def test_iziplongest(self):

    # Having a for loop seems important
    for args in ['abc']:
        self.assertEqual(1, 2)

    pass  # Having this seems important

    # The bug was the except jumping back
    # to the beginning of this for loop
    for stmt in [
        "izip_longest('abc', fv=1)",
    ]:
        try:
            eval(stmt)
        except TypeError:
            pass
        else:
            self.fail()

becomes:

def test_iziplongest(self):

    # Having a for loop seems important
    for args in ['abc']:
        self.assertEqual(1, 2)

    pass  # Having this seems important

    # The bug was the except jumping back
    # to the beginning of this for loop
    for stmt in [
        "izip_longest('abc', fv=1)",
    ]:
        try:
            eval(stmt)
        except TypeError:
            pass
     
        self.fail()

[rocky]

Looking at disassembly between the two, the difference is a single JUMP instruction which in the try/else is a JUMP_BACK (to the loop) while in the try (no else) it is JUMP_FORWARD to the self.fail().

Given this, probably the best thing to do would be to wait a separate control-flow pass.

[pythonengineer]

Similar problem in Python 2.4 where a regular try: except: will be decompiled as try: except: else:

[rocky]

@pythonengineer To be clear this is not about there being a bug in decompiling python 2.4 bytecode, but that when run in python 2.4 interpreter it works the way all the other Python versions work. And that is what we strive for.