Re: [Python-Dev] API design question: how to extend sys.settrace()?
Victor, thank you for starting this conversation. Nick, I just looked at your patch and I think it is a better solution than mine, because it does not involve adding to or changing the sys API. I will close my pull request.
The reason for my interest in this area is that I’m experimenting with a code coverage tool that does per-opcode tracing. I just updated it to use the new f_trace_opcodes feature and it *almost* worked: Nick’s implementation calls the opcode trace before updating the line number, whereas my version updated line numbers first, so the event stream is slightly different.
See: https://github.com/python/cpython/commit/5a8516701f5140c8c989c40e261a4f4e20e...
From my perspective it makes more sense to do the update to f_lineno first, followed by the opcode trace, because then line events and opcode events corresponding to the same opcode will have the same line number; as it is they come out different.
Is the current order intentional? Otherwise I’ll submit a patch.
Either way, I’m really happy that this functionality has made it into master!
Thanks, George
On 28 September 2017 at 06:23, George King gwk.lists@gmail.com wrote:
Victor, thank you for starting this conversation. Nick, I just looked at your patch and I think it is a better solution than mine, because it does not involve adding to or changing the sys API. I will close my pull request.
The reason for my interest in this area is that I’m experimenting with a code coverage tool that does per-opcode tracing. I just updated it to use the new f_trace_opcodes feature and it *almost* worked: Nick’s implementation calls the opcode trace before updating the line number, whereas my version updated line numbers first, so the event stream is slightly different.
See: https://github.com/python/cpython/commit/5a8516701f5140c8c989c40e261a4f4e20e...
From my perspective it makes more sense to do the update to f_lineno first, followed by the opcode trace, because then line events and opcode events corresponding to the same opcode will have the same line number; as it is they come out different.
Is the current order intentional? Otherwise I’ll submit a patch.
Line numbers simply weren't relevant to my use case (injecting inconveniently timed exceptions), so I never checked whether or not f_lineno was accurate when the trace event was emitted.
So yeah, a follow-up bug report and PR to fix that would be appreciated (no need for a NEWS entry, since it's a bug in a not-yet-released feature).
Cheers, Nick.
participants (2)
-
George King -
Nick Coghlan