[Python-Dev] about line numbers

Tim Peters tim_one@email.msn.com
Thu, 12 Aug 1999 20:07:32 -0400


[Vladimir Marangozov]
> Is python with vs. without "-O" equivalent today regarding
> line numbers?
>
> Are SET_LINENO opcodes a plus in some situations or not?

In theory it should make no difference, except that the trace mechanism
makes a callback on each SET_LINENO, and that's how the debugger implements
line-number breakpoints.  Under -O, there are no SET_LINENOs, so debugger
line-number breakpoints don't work under -O.

I think there's also a sporadic buglet, which I've never bothered to track
down:  sometimes a line number reported in a traceback under -O (&, IIRC,
it's always the topmost line number) comes out as a senseless negative
value.

> Next, I see quite often several SET_LINENO in a row in the beginning
> of code objects due to doc strings, etc. Since I don't think that
> folding them into one SET_LINENO would be an optimisation (it would
> rather be avoiding the redundancy), is it possible and/or reasonable
> to do something in this direction?

All opcodes consume time, although a wasted trip or two around the eval loop
at the start of a function isn't worth much effort to avoid.  Still, it's a
legitimate opportunity for provable speedup, even if unmeasurable speedup
<wink>.

Would be more valuable to rethink the debugger's breakpoint approach so that
SET_LINENO is never needed (line-triggered callbacks are expensive because
called so frequently, turning each dynamic SET_LINENO into a full-blown
Python call; if I used the debugger often enough to care <wink>, I'd think
about munging in a new opcode to make breakpoint sites explicit).

immutability-is-made-to-be-violated-ly y'rs  - tim