Skip to content

Commit eb7114c

Browse files
committed
PEP 830: Tighten three Rejected Ideas / Open Issues entries
Shorten the None-when-unset and coarse-clock rejections, and replace the "can be added later" closer in the time-of-first-raise open issue with a note that early-construction patterns are not common in practice.
1 parent 66d717e commit eb7114c

1 file changed

Lines changed: 8 additions & 11 deletions

File tree

peps/pep-0830.rst

Lines changed: 8 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -537,19 +537,16 @@ Returning ``None`` When Unset
537537
Returning ``None`` rather than ``0`` when no timestamp was collected would be
538538
slightly more Pythonic, but ``__timestamp_ns__`` is exposed as a plain
539539
``int64_t`` member descriptor on the C struct. Supporting ``None`` would
540-
require a custom getter and boxed storage, adding complexity for little
541-
practical benefit; ``0`` is an unambiguous sentinel for a Unix-epoch
542-
nanosecond value.
540+
require a custom getter and boxed storage. ``0`` is unambiguous.
543541

544542
Using a Coarse Clock
545543
--------------------
546544

547-
``CLOCK_REALTIME_COARSE`` (and equivalents on other platforms) is faster to
548-
read than ``CLOCK_REALTIME`` but typically offers only millisecond
549-
resolution, which is insufficient for distinguishing exceptions raised in
550-
quick succession. The reference implementation uses ``PyTime_TimeRaw``,
551-
which reads the standard wall clock at full resolution; benchmarking shows
552-
this cost is not observable in practice.
545+
The reference implementation uses ``PyTime_TimeRaw``, which reads the
546+
standard wall clock at full resolution; benchmarking shows this cost is not
547+
observable in practice. A coarse clock such as ``CLOCK_REALTIME_COARSE``
548+
would be low resolution, insufficient for many needs, for no measurable
549+
benefit.
553550

554551

555552
Open Issues
@@ -587,8 +584,8 @@ instantiation time, was suggested. This is deferred rather than rejected:
587584
it would cover the case where an exception is constructed well in advance of
588585
being raised, but it requires identifying a clean hook point in the
589586
interpreter's raise paths (see `Instantiation Time vs. Raise Time`_) and
590-
defining the semantics for re-raise. It can be added later without breaking
591-
the attribute proposed here.
587+
defining the semantics for re-raise. We are not aware of code commonly
588+
using a pattern of constructing an exception well before its first use.
592589

593590

594591
Acknowledgements

0 commit comments

Comments
 (0)