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.

Author: gpshead

peps/pep-0830.rst

@@ -537,19 +537,16 @@ Returning ``None`` When Unset
 Returning ``None`` rather than ``0`` when no timestamp was collected would be
 slightly more Pythonic, but ``__timestamp_ns__`` is exposed as a plain
 ``int64_t`` member descriptor on the C struct.  Supporting ``None`` would
-require a custom getter and boxed storage, adding complexity for little
-practical benefit; ``0`` is an unambiguous sentinel for a Unix-epoch
-nanosecond value.
+require a custom getter and boxed storage.  ``0`` is unambiguous.
 
 Using a Coarse Clock
 --------------------
 
-``CLOCK_REALTIME_COARSE`` (and equivalents on other platforms) is faster to
-read than ``CLOCK_REALTIME`` but typically offers only millisecond
-resolution, which is insufficient for distinguishing exceptions raised in
-quick succession.  The reference implementation uses ``PyTime_TimeRaw``,
-which reads the standard wall clock at full resolution; benchmarking shows
-this cost is not observable in practice.
+The reference implementation uses ``PyTime_TimeRaw``, which reads the
+standard wall clock at full resolution; benchmarking shows this cost is not
+observable in practice.  A coarse clock such as ``CLOCK_REALTIME_COARSE``
+would be low resolution, insufficient for many needs, for no measurable
+benefit.
 
 
 Open Issues
@@ -587,8 +584,8 @@ instantiation time, was suggested.  This is deferred rather than rejected:
 it would cover the case where an exception is constructed well in advance of
 being raised, but it requires identifying a clean hook point in the
 interpreter's raise paths (see `Instantiation Time vs. Raise Time`_) and
-defining the semantics for re-raise.  It can be added later without breaking
-the attribute proposed here.
+defining the semantics for re-raise.  We are not aware of code commonly
+using a pattern of constructing an exception well before its first use.
 
 
 Acknowledgements