On 4/1/06, Jeremy Hylton <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
