This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Mark.Shannon
Recipients Mark.Shannon, brett.cannon, dino.viehland, eric.snow, fabioz, vstinner
Date 2019-11-21.15:08:05
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1574348886.05.0.765635897291.issue38500@roundup.psfhosted.org>
In-reply-to
Content
Fabio,

Can you give me a specific example where changing the bytecode via the `__code__` attribute of a function does not work as expected?

I am assuming that adding a breakpoint on a line is equivalent to adding `breakpoint();` at the beginning of that line. If the bytecode of a function is modified dynamically, say by a decorator, then it is unclear what should be done, and it is hard to claim that any particular approach is more correct.
However, assuming that the change is well defined and keeps the mapping to the original code, then adding a breakpoint to the modified code should work just as well before or after modification.

As an example, consider http://code.activestate.com/recipes/277940-decorator-for-bindingconstants-at-compile-time/ which provides a means of converting global variable reads to constants.  In that case the order in which the decorator and breakpoint insertion are applied shouldn't matter.

I propose a new method on code objects `withCallAtLine(callable: Callable[], line:int)` which returns a new code object with calls to the given callable at the given line.
A breakpoint can then be inserted at line L in function f with `f.__code__ = f.__code__.withCallAtLine(sys.breakpoint, L)`.
History
Date User Action Args
2019-11-21 15:08:06Mark.Shannonsetrecipients: + Mark.Shannon, brett.cannon, vstinner, fabioz, dino.viehland, eric.snow
2019-11-21 15:08:06Mark.Shannonsetmessageid: <1574348886.05.0.765635897291.issue38500@roundup.psfhosted.org>
2019-11-21 15:08:06Mark.Shannonlinkissue38500 messages
2019-11-21 15:08:05Mark.Shannoncreate