Author Mark.Shannon
Recipients Mark.Shannon, brett.cannon, dino.viehland, eric.snow, fabioz, vstinner
Date 2019-11-08.19:10:00
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1573240201.07.0.186636537113.issue38500@roundup.psfhosted.org>
In-reply-to
Content
It sounds to me like `PyInterpreterState.eval_frame` is being used to lazily modify the bytecode to support breakpoints.

I can see no reason why changing the bytecode can't be done via `function.__code__`.
Suppose the code-object with the breakpoint add is `bcode`, then to turn on the breakpoint:
original_code = f.__code__
f.__code__ = bcode

and to turn it off
f.__code__ = original_code


The JVM supports bytecode instrumentation (via class loaders). It works well, as it provides a clear way for third party tools to modify the behaviour of a particular piece of code without violating any of the invariants of the interpreter. 
We don't really advertise setting `function.__code__` as a way to add low-impact breakpoints or profiling, but it is there.

If this use case is important, and it sounds like it is, then a better option would be to offer library support for adding and removing breakpoints/instrumentation.
This would have the advantage of being composable in a way that changing `PyInterpreterState.eval_frame` is not; in other words, it would be possible for one tool to add profiling and another to add breakpoints and have both work correctly.

I can write up a PEP if necessary.
History
Date User Action Args
2019-11-08 19:10:01Mark.Shannonsetrecipients: + Mark.Shannon, brett.cannon, vstinner, fabioz, dino.viehland, eric.snow
2019-11-08 19:10:01Mark.Shannonsetmessageid: <1573240201.07.0.186636537113.issue38500@roundup.psfhosted.org>
2019-11-08 19:10:01Mark.Shannonlinkissue38500 messages
2019-11-08 19:10:00Mark.Shannoncreate