[Python-Dev] line numbers, pass statements, implicit returns

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