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/