This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: line numbers off by 1 in dis
Type: Stage:
Components: Interpreter Core Versions:
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: nascheme Nosy List: brett.cannon, nascheme, nnorwitz
Priority: normal Keywords:

Created on 2005-07-28 02:18 by brett.cannon, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (8)
msg25886 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2005-07-28 02:18
test_dis.py:test_dis is failing for two reasons: the
line numbers are off by one (need to be bumped up) and
the peepholer is not being used and thus the
LOAD_CONST(None);RETURN_VALUE idiom is still being
tacked on to everything.

The former problem needs to be fixed while the latter
is not an issue and thus the test needs to get tweaked
to allow for the return.
msg25887 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2005-07-28 02:40
Logged In: YES 
user_id=357491

OK, so first oddity; in both Python 2.5 and the AST branch
co_firstlineno, when working on a function at the
interpreter prompt, is set to 1.  But if you look at
co_lnotab, AST has '\x05\x01' while 2.5 has
'\x00\x01\x05\x01'.  If you tack on another line to the test
function, AST has '\x05\x01\x05\x01' while 2.5 has
'\x00\x01\x05\x01\x05\x01'.

The critical thing is the initial '\x00\x01'.  Looks like
2.5 tacks that on or somehow decides it needs to state the
initial line at 0 is a byte long.
msg25888 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2005-07-28 03:59
Logged In: YES 
user_id=357491

I have test_dis now passing thanks to some refactoring to
handle the initial line.  Now I just need to try to fix
test_bug_708901.
msg25889 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2005-07-28 05:25
Logged In: YES 
user_id=357491

I don't think this last problem is easily fixed.  If you
look at the AST, only statements have a lineno attribute. 
But it is an expression that is on another line from the
main line of the statement.  I cannot think of any way to
get the line information from the statement without adding a
lineno attribute to expressions and removing it from
statements.  That should give the coverage needed to know
when another line is being outputted.
msg25890 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2005-07-28 05:51
Logged In: YES 
user_id=357491

Rev. 1.1.2.110 of Python/newcompile.c has the fix for
test_dis:test_dis.

The more thinking I do about it the more I realize that
expression nodes in the AST will need to keep a lineno
attribute in order to have lnotab to be set properly.  That
will not be a fun patch to do.
msg25891 - (view) Author: Neil Schemenauer (nascheme) * (Python committer) Date: 2005-10-07 19:36
Logged In: YES 
user_id=35752

As you say, this looks like it will be tedious to fix. 
Maybe we could change the ast node constructors to take
lineno as an optional argument (e.g. using va_list).
msg25892 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2005-10-07 20:05
Logged In: YES 
user_id=357491

Maybe, but what would that buy us?  We can make the
attribute optional on expression nodes and slowly work it
all in, but it will need to be done at some point.  We could
make this the last major fix and deal with everything else
that does not rely on this since it is a rather shallow fix
in and of itself.
msg25893 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2005-10-24 02:54
Logged In: YES 
user_id=33168

Has this report been overcome by events?  Is it still
relevant?  If so, what about the bug report mentioned below?
History
Date User Action Args
2022-04-11 14:56:12adminsetgithub: 42226
2005-07-28 02:18:27brett.cannoncreate