[Python-Dev] line numbers, pass statements, implicit returns (original) (raw)

Jeremy Hylton jeremy at alum.mit.edu
Sat Apr 1 19:17:27 CEST 2006

There are several test cases in test_trace that are commented out. We did this when we merged the ast-branch and promised to come back to them. I'm coming back to them now, but the test aren't documented well and the feature they test isn't specified well.

The failing tests I've looked at so far involving pass statements and implicit "return None" statements generated by the compiler. The tests seem to verify that

1) if you have a function that ends with an if/else where the body

of the else is pass, there is no line number associated with the return 2) if you have a function that ends with a try/except where the body of the except is pass, there is a line number associated with the return.

Here's a failing example

def ireturn_example(): a = 5 b = 5 if a == b: b = a+1 else: pass

The code is traced and test_trace verifies that the return is associated with line 4!

In these cases, the ast compiler will always associate a line number with the return. (Technically with the LOAD_CONST preceding the RETURN_VALUE.) This happens pretty much be accident. It always associates a line number with the first opcode generated after a new statement is visited. Since a Pass statement node has no opcode, the return generates the first opcode.

Now I could add some special cases to the compiler to preserve the old behavior, the question is: Why bother? It's such an unlikely case (an else that has no effect). Does anyone depend on the current behavior for the ireturn_example()? It seems sensible to me to always generate a line number for the pass + return case, just so you see the control flow as you step through the debugger.

The other case that has changed is that the new compiler does not generate code for "while 0:" I don't remember why <0.5 wink>. There are several test cases that verify line numbers for code using this kind of bogus construct. There are no lines anymore, so I would change the tests so that they don't expect the lines in question. But I have no idea what they are trying to test. Does anyone know?

Jeremy

More information about the Python-Dev mailing list