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

[Guido van Rossum]

On 4/1/06, Jeremy Hylton <jeremy at alum.mit.edu> wrote:
> 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.

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/)