Skip to content
Draft
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Add open issues about timestamp collection and control flow exceptions
Added two important open issues to the PEP:

1. Whether to always collect timestamps unconditionally (performance
   testing shows it's cheap) and the implications for pickle size and
   cross-version compatibility testing

2. Configuration of control flow exception exclusions (StopIteration,
   AsyncStopIteration) and whether subclasses should be included, noting
   the performance constraints of the hot path

🤖 Generated with Claude Code (https://claude.ai/code)

Co-Authored-By: Claude <[email protected]>
  • Loading branch information
gpshead and claude committed Sep 17, 2025
commit 5a25936a7b123182c06a517e2182ce67dce05038
25 changes: 25 additions & 0 deletions peps/pep-08XX.rst
Original file line number Diff line number Diff line change
Expand Up @@ -356,6 +356,31 @@ Open Issues

3. Should the timestamp format be customizable beyond the predefined options?

4. **Always collecting timestamps vs. conditional collection**: Performance testing
shows that collecting timestamps at exception instantiation time is cheap enough
to do unconditionally. If we always collect them:

- The ``__timestamp_ns__`` attribute would always exist, simplifying the
implementation and making the pickle code cleaner (though pickled exceptions
would be slightly larger)
- Exceptions will unpickle cleanly on older Python versions (they'll just have
an extra attribute that older versions ignore)
- However, we don't currently have extensive testing for cross-version pickle
compatibility of exceptions with new attributes. Should we add such tests?
Is this level of compatibility testing necessary?

5. **Control flow exception handling**: The current implementation does not collect
timestamps for ``StopIteration`` and ``AsyncStopIteration`` to avoid performance
impact on normal control flow. Several questions arise:

- Should this exclusion be configurable at runtime?
- Should it apply to subclasses of these exceptions?
- The check for these specific exceptions is in the hot path of exception
creation and must be extremely fast. The current implementation uses a simple
type check for performance. Adding complexity like subclass checks or a
configurable tuple of excluded exceptions would impact performance. Is the
current simple approach acceptable?


Acknowledgements
================
Expand Down
Loading