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