gh-132502: Implements PEP-830 adding timestamps to tracebacks#129337
Draft
gpshead wants to merge 79 commits intopython:mainfrom
Draft
gh-132502: Implements PEP-830 adding timestamps to tracebacks#129337gpshead wants to merge 79 commits intopython:mainfrom
gpshead wants to merge 79 commits intopython:mainfrom
Conversation
This came up at work as a suggestion to make debugging what happened in big async servers with lots of exception groups and exceptions easier. Timestamps when emitting exception groups containing tracebacks often with their own nested causes would allow some semblance of order to be understood. This is a demo. If we want such a feature, we should settle on semantics in a Discuss thread and write it up as a PEP. This should be simpler than exception notes (PEP-678) was. One thought was just to store the timestamp as a note; but that'd involve string and list creation on every exception. Performance testing needs to be done. This is the kind of thing that is visually distracting, so not all applications want to _see_ the timestamps. A knob to turn that on for those who do seems more useful rather than making that the default. But the performance impact of merely collecting the timestamps is worth knowing.
Avoids a 15% regression in the pyperformance async_generators suite.
Tested with `PYTHON_TRACEBACK_TIMESTAMPS=ns` set. First pass. Further review could rework some of these changes. Explicit tests for the new feature have yet to be added.
gpshead
force-pushed
the
traceback-timestamps
branch
from
6c85054 to
53b5500
Compare
Better docs, improved tests. Claude Code using Sonnet 3.7 helped with this, but that was a bit of a battle as our CPython code context size for this type of change is huge.
TODO: performance testing - this increases the conditional load on every BaseException instantiation with that interp->config.field && field[0] check. If needed, we could cache the "collect or not" bool in a static global as it is fair to say this is a process wide setting rather than per interpreter, but ugh.
"us" is what "1" means, not what you get when no value is provided. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
… other processes in tests as well
gpshead
changed the title
Resolve conflicts in Lib/subprocess.py (adopt generic sorted xoptions loop) and Objects/exceptions.c (integrate _PyTuple_FromPair with timestamp-aware __reduce__ methods).
gpshead
requested review from
AA-Turner,
FFY00,
brettcannon,
emmatyping,
ericsnowcurrently,
erlend-aasland,
ezio-melotti,
gaogaotiantian,
hugovk,
iritkatriel,
ncoghlan,
terryjreedy,
vsajip,
warsaw and
webknjaz
as code owners
Member
Author
|
Hmm, I'll leave this as "Draft" while the PEP discussion kicks off: https://discuss.python.org/t/pep-830-add-timestamps-to-exceptions-and-tracebacks/106942 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PEP coming together in python/peps#4592 - that's a much better description. Go read PEP 830.
Updates: [edits]
I've done performance testing. It now appears to be a no-op (no meaningful regression) as desired performance wise on Linux. For that to be true, I had to add the one special case I suspected might matter: Don't collect the timestamp on
StopIterationandAsyncStopIterationas those are not infrequent error exceptions, but a normal part of application control flow. Without that, one of the async pyperformance benchmarks showed a significant performance hit of over 10%.I've changed the year ago early original to not emit the timestamps by default and after discussing at our sprint (Cambridge 2025-09) to not even collect the data when display is disabled. If you set the
PYTHON_TRACEBACK_TIMESTAMPS=environment variable to one of eitherusor1,ns, oriso, timestamps will be enabled at exception instantiation time and intracebackmodule display output. See the documentation in the PR & see the PEP.