[Vladimir Marangozov] > ... > And the whole point of the solution we were thinking of is to > make sure that the debugger (and other objects, like > tracebacks) do read the line number only when the main loop > fires a "line" event via a hook. > > Given the state of the art, however, nobody can guarantee that > the line number is not fetched in legacy code from the frame > directly, through f.lineno (for whatever purpose). I really don't think we care about that. Guido, do we <wink>? f_lineno is conceptually an internal implementation detail of frame objects, and Guido has often warned that if you access the internals you're on your own (I don't think even Michael's bytecodehacks cares about this one <wink>). So long as all uses of f_lineno in the std distribution can be faked, I think it's fine to just get rid of that member. WRT your later msg, strongly doubt tstate->ticker will help: it's an integer in range(tstate->interp->checkinterval + 1), and wraps around over & over. Besides, the modular base (checkinterval) can be changed by the user at any time. tstate->ticker is thus but the circular shadow of a legion of ghosts. It isn't worth all these brain cells just to preserve an internal detail! OK, it would be worth it if it were easy <wink> -- but it's not.
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