[Patches] [ python-Patches-514997 ] remove extra SET_LINENOs

[noreply@sourceforge.net]

Patches item #514997, was opened at 2002-02-08 16:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=514997&group_id=5470

Category: Parser/Compiler
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Neil Schemenauer (nascheme)
Summary: remove extra SET_LINENOs

Initial Comment:
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.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-25 07:40

Message:
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.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-24 00:29

Message:
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).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-01 17:42

Message:
Logged In: YES 
user_id=6380

Can you find someone interested in answering the inspect
question? Otherwise this patch is stalled...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=514997&group_id=5470