[Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment)

Tim Peters tim_one@email.msn.com
Mon, 31 Jul 2000 00:23:56 -0400

[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

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.