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 fabioz
Recipients Mark.Shannon, brett.cannon, dino.viehland, eric.snow, fabioz, vstinner
Date 2019-11-04.11:07:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1572865654.27.0.623557950815.issue38500@roundup.psfhosted.org>
In-reply-to
Content
@Mark Shannon what I do is change the code object of the frame about to be evaluated to add a programmatic breakpoint, to avoid the need to have the trace function set at contexts that would need to be traced (after changing the frame.f_code it goes on to call the regular _PyEval_EvalFrameDefault), so, the user-code runs at full speed on all contexts (there's still added overhead on a function call to decide if the code object needs to be changed, but that'd happen on the regular tracing code too).

Note that this does not change the semantics of anything as it calls the regular _PyEval_EvalFrameDefault, so, the worries you're listing shouldn't be a concern in this particular use-case.

Also note that until Python 3.7 this was easy to change, and that's still possible in Python 3.8 (the only thing is that now it's less straightforward).

Note that my use is much simpler that the original intent of the frame evaluator -- my use case could be solved by having a callback to change the code object before the frame execution -- but as far as I know, right now, the way to do that is through the frame evaluation API.
History
Date User Action Args
2019-11-04 11:07:34fabiozsetrecipients: + fabioz, brett.cannon, vstinner, dino.viehland, Mark.Shannon, eric.snow
2019-11-04 11:07:34fabiozsetmessageid: <1572865654.27.0.623557950815.issue38500@roundup.psfhosted.org>
2019-11-04 11:07:34fabiozlinkissue38500 messages
2019-11-04 11:07:33fabiozcreate