Mark Shannon <m...@hotpy.org> added the comment:
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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue38500> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
