Tim Peters wrote:
>
> [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!
It is! <wink>
> OK, it would be worth it if it were easy <wink> -- but it's not.
It is! I think I found the solution :-)
Whenever f.f_lineno is accessed, the compiler generates a LOAD_ATTR
relative to f. Therefore, updating f->f_lasti = INSTR_OFFSET() in
LOAD_ATTR + trapping "lineno" access in frameobject.c with
PyCode_Addr2Line(f->f_lasti) ensures that we'll always get the
right line number.
Of course, this makes the update of f->f_lasti for every LOAD_ATTR,
but given the ranking of SET_LINENO compared to LOAD_ATTR in the
DXP and MAL's frequency charts, I think this is a pure win!
Et voila <wink>. I'll update my patch at SF later.
now-back-to-work'ly y'rs
--
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