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: remove extra SET_LINENOs
Type: Stage:
Components: Interpreter Core Versions:
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: nascheme Nosy List: gvanrossum, nascheme, nnorwitz, tim.peters
Priority: low Keywords: patch

Created on 2002-02-08 21:22 by nnorwitz, last changed 2022-04-10 16:04 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
lineno-patch nnorwitz, 2002-02-08 21:22 fix compile.c and test_hotspot.py to remove consecutive SET_LINENOs
Messages (4)
msg38901 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2002-02-08 21:22
This patch removes consecutive SET_LINENOs.
The patch fixes test_hotspot, but does not fix
a failure in inspect.  I wasn't sure what
was the problem was or why SET_LINENO would
matter for inspect.
msg38902 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2002-03-01 22:42
Logged In: YES 
user_id=6380

Can you find someone interested in answering the inspect
question? Otherwise this patch is stalled...
msg38903 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2002-03-24 05:29
Logged In: YES 
user_id=31435

Neal, do you have your editor set to insert spaces instead 
of tabs, and to consider "a tab" to be four spaces?  Guido 
wrote this file using hard tabs considered as 8-space 
gimmicks, and the after-patch code is kinda gruesome due to 
the mixture of indentation styles.

Second, why do you think a hard-coded 0xffff is something 
interesting for line numbers?  Or are you just giving up 
when line numbers are >= 2**16?  The code is mysterious 
here and needs a comment.  It's probably not good to leave 
the code in a state where adjacent SET_LINENOs are 
collapsed if and only if the line numbers "aren't big" 
(then code using line numbers can't guess whether they are 
or aren't collapsed without duplicating the same lumpy 
logic).

Third, c_lnotab is extremely delicate, historically subject 
to miserable rare bugs.  If you've read the long comment 
block explaining it near the top of this file, I'd 
appreciate an argument (in code comments more than here 
<wink>) for why just mucking with the last pair in a 
sequence of offset pairs can't break the subtle correctness 
property explained in the comment block.

Finally, it's definitely worth tracking down why 
test_inspect fails:  that test is difficult to understand, 
but the bottom line is that it's provoking an exception 
traceback and asserting that the computed line numbers 
correspond to the actual lines that are failing.  The 
failing case provokes a three-frame traceback, and 2 of the 
3 line numbers are wrong after the patch (the first is off 
by 1, and the third is off by 3; the frame in the middle 
gets the right line number).
msg38904 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2002-03-25 12:40
Logged In: YES 
user_id=33168

I'm rejected this patch because it would take a lot of work
to get this patch to the point where it would be good enough
for inclusion.

Now to answer Tim's questions.  Tabs vs spaces:  depends on
the day.  I use both emacs & vi, emacs does convert to
spaces.  But I must have screwed something up.

0xffff was only a hack to not deal with line numbers > 2
**16.  I was going for bang for the buck.  I agree it would
be best to remove this limitation.
History
Date User Action Args
2022-04-10 16:04:57adminsetgithub: 36053
2002-02-08 21:22:56nnorwitzcreate