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 <>
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.
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: <>
2019-11-08 19:10:01Mark.Shannonlinkissue38500 messages
2019-11-08 19:10:00Mark.Shannoncreate