gh-132502: Implements PEP-829 adding timestamps to tracebacks#129337
Draft
gpshead wants to merge 77 commits intopython:mainfrom
Draft
gh-132502: Implements PEP-829 adding timestamps to tracebacks#129337gpshead wants to merge 77 commits intopython:mainfrom
gpshead wants to merge 77 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.
gpshead
added
the
🔨 test-with-refleak-buildbots
|
🤖 New build scheduled with the buildbot fleet by @gpshead for commit 77ffb5a 🤖 Results will be shown at: https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F129337%2Fmerge If you want to schedule another build, you need to add the 🔨 test-with-refleak-buildbots label again. |
bedevere-bot
removed
the
🔨 test-with-refleak-buildbots
gpshead
commented
Jun 8, 2025
- Add cross-references between command line flags and environment variables - Clarify default behavior when PYTHON_TRACEBACK_TIMESTAMPS is unset - Simplify traceback.rst wording to use "canonical output" - Fix alphabetical ordering in test_config.py - Improve comment formatting in test_sys.py for better readability 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
The functionality is already provided by force_color(False) and force_not_colorized() which were added since this branch started. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
dcolascione
reviewed
Aug 28, 2025
This comment was marked as spam.
This comment was marked as spam.
gpshead
force-pushed
the
traceback-timestamps
branch
from
82c6246 to
7e6d542
Compare
Resolved conflicts: - .github/workflows/build.yml: keep both traceback_timestamps and test-opts - .github/workflows/reusable-ubuntu.yml: keep both input parameters - Doc/using/cmdline.rst: add traceback_timestamps after new main entries - Include/cpython/initconfig.h: add traceback_timestamps after pymalloc_hugepages - Python/sysmodule.c: add traceback_timestamps after lazy_imports in flags Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…PR and mention that in a comment to avoid it recurring
gpshead
force-pushed
the
traceback-timestamps
branch
from
962d209 to
7d2a4d3
Compare
30 tasks
gpshead
changed the title
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Resolved conflicts in sysmodule.c (keep 3.13 in comment) and test_sys.py (adopt main's split of indexable vs name-only sys.flags attributes, add traceback_timestamps to the name-only section). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Resolved conflict in initconfig.c --help-env: main cleaned up duplicate entries; keep only our PYTHON_TRACEBACK_TIMESTAMPS addition. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
"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
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 the PEP.
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, 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.