[Python-Dev] SET_LINENO and python options

[M.-A. Lemburg]

Vladimir Marangozov wrote:
> 
> M.-A. Lemburg wrote:
> >
> > [Vladimir on removing SET_LINENO opcodes per default]
> >
> > Is there any reason why we can't just use traceback.tb_lineno()
> > + maybe an equivalent C function instead of adding useless opcodes
> > into the byte code stream ?
> >
> 
> Yes - you seem to have missed half the story <wink>. How would you
> generate callbacks (fire "line" events) from within the mainloop
> when a sys.settrace function is set and the PC starts executing
> opcodes corresponding to a new line number?

Good question :-) You're right: I forgot about the trace function
call in the SET_LINENO opcode.
 
> Note that we don't "add" any new opcodes, and in the scheme I presented
> CALL_TRACE is also internal to eval_code2(), like the copy of co_code,
> but I eventually decided to show it in opcodes.h.

With "add" I meant the SET_LINENO opcode... remove the "useless"
from my comment above ;-)
 
> SET_LINENO is not generated anymore and is reduced to a NOOP in ceval,
> CALL_TRACE is introduced only for the callbacks. For b/w compatibility
> (of .pyc files) I think we can't just "get rid" of it.
> 
> And now that the game is over with finding the solution to f.f_lineno's
> access, the proposal about "python -g" which preserves SET_LINENO makes
> sense (at least for visualizing SET_LINENO in a disassembly).

BTW, we already have "python -d" which sets the debugging
flag. You could simply use that flag for generating the SET_LINENO
opcodes.

Still, I think that the SET_LINENO issue is not really all that
important: we have "python -O" which removes the opcodes. Perhaps
moving the opcode a bit further down in the big switch would
help CPU caches for production code (running under "python -O")...

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/