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

Guido van Rossum guido at python.org
Sun Apr 2 08🔞17 CEST 2006

On 4/1/06, Jeremy Hylton <jeremy at alum.mit.edu> wrote:

There are several test cases in testtrace 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 ireturnexample(): a = 5 b = 5 if a == b: b = a+1 else: pass The code is traced and testtrace 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 LOADCONST preceding the RETURNVALUE.) 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 ireturnexample()? 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.

Makes sense to me. I can't imagine what this was testing except perhaps a corner case in the algorithm for generating the (insanely complicated) linenumber mapping table.

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?

Not me. This is definitely not part of the language spec! :-)

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list