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