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?
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.
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).
--
Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4