Skip to content

Commit 9a118c2

Browse files
committed
PEP 678: more rejected ideas
1 parent b072483 commit 9a118c2

File tree

1 file changed

+46
-0
lines changed

1 file changed

+46
-0
lines changed

pep-0678.rst

Lines changed: 46 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -215,6 +215,9 @@ exception chaining, and are unnecessary with ``BaseException.__note__`` :
215215
Explanation: # Hence this PEP!
216216
You can reproduce this error by ...
217217
218+
**Where these factors are not problematic, we encourage use of exception chaining
219+
rather than** ``__note__`` .
220+
218221

219222
Subclass Exception and add ``__note__`` downstream
220223
--------------------------------------------------
@@ -229,6 +232,49 @@ proposed ``__note__`` semantics, but this would be rarely and inconsistently
229232
applicable.
230233

231234

235+
Augment the ``raise`` statement
236+
-------------------------------
237+
One discussion proposed ``raise Exception() with "note contents"`` .
238+
This would be a strictly additional feature over adding the attribute and modifying
239+
the traceback-formatting code, and we do not expect ``__note__`` to be so
240+
frequently-used as to justify new syntax.
241+
242+
243+
Structured API rather than string attribute
244+
-------------------------------------------
245+
Instead of a string-or-None, ``__note__`` could be a new object with a structured API
246+
and a ``__str__()`` method for printing at trackback time.
247+
We have not identified any scenario where libraries would want to do anything but either
248+
concatenate or replace notes, and so the additional complexity does not seem justified.
249+
250+
Permitting ``__note__`` to be "None or any object with a ``__str__()`` method" would
251+
allow for experimentation with such proposals, and forward-compatibility one was adopted.
252+
We see this as a flexibility/usability tradeoff, and in the absence of any concrete
253+
use-case we narrowly prefer to guarantee that notes are strings but remain open to
254+
revisiting the decision.
255+
256+
257+
Add a helper function ``contexlib.add_exc_note()``
258+
--------------------------------------------------
259+
We don't expect notes to be used frequently enough to justify this either, but
260+
provide the following recipe::
261+
262+
@contextlib.contextmanager
263+
def add_exc_note(
264+
note: str,
265+
exc: type[BaseException] | tuple[type[BaseException], ...] = BaseException,
266+
concatenate: str | None = "\n\n",
267+
):
268+
try:
269+
yield
270+
except exc as err:
271+
if concatenate is None or err.__note__ is None:
272+
err.__note__ = note
273+
else:
274+
err.__note__ = err.__note__ + concatenate + note
275+
raise
276+
277+
232278
Store notes in ``ExceptionGroup`` s
233279
-----------------------------------
234280
Initial discussions proposed making a more focussed change by thinking about how to

0 commit comments

Comments
 (0)