Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PEP 678: Update proposal with .add_note() and acknowledgements section #2331

Merged
merged 5 commits into from
Feb 20, 2022
Merged
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
19 changes: 10 additions & 9 deletions pep-0678.rst
Original file line number Diff line number Diff line change
Expand Up @@ -121,7 +121,7 @@ Non-goals
---------
Tracking multiple notes as a tuple, rather than by concatenating strings when
notes are added, is intended to maintain the distinction between the
individual notes. This might be required in specialized use cases, such
individual notes. This might be required in specialized use cases, such
as translation of the notes by packages like ``friendly-traceback``.

However, ``__notes__`` is *not* intended to carry structured data. If your
Expand All @@ -133,15 +133,15 @@ instead (or additionally) choosing a convention for an attribute, e.g.
As a rule of thumb, we suggest that you should prefer `exception chaining
<https://docs.python.org/3/tutorial/errors.html#exception-chaining>`__ when the
error is going to be re-raised or handled as an individual error, and prefer
Zac-HD marked this conversation as resolved.
Show resolved Hide resolved
``.add_note()`` when you are collecting multiple exception objects to handle
together or later. [1]_
``.add_note()`` when you do not know or wish to change the exception type or
Zac-HD marked this conversation as resolved.
Show resolved Hide resolved
are collecting multiple exception objects to handle together. [1]_


Specification
=============

``BaseException`` gains a new read-only field ``__notes__``, an initially empty
tuple, and a new method ``.add_note(note: str | None, *, replace:
``BaseException`` gains a new read-only attribute ``__notes__``, an initially
empty tuple, and a new method ``.add_note(note: str | None, *, replace:
bool=False)``. If ``note`` is not ``None``, it is added to the exception's
notes which appear in the standard traceback after the exception string. If
``replace`` is true, all previously existing notes are removed before the new
Expand All @@ -165,8 +165,9 @@ subject to breakage without warning
<https://docs.python.org/3/reference/lexical_analysis.html#reserved-classes-of-identifiers>`__.
We are also unaware of any code which *would* be broken by adding ``__notes__``.

While ``add_note()`` is a fairly common method name, our Google and GitHub
searches did not find any exception classes which define such a method.
While ``add_note()`` is a fairly common method name, our Google and `GitHub
Zac-HD marked this conversation as resolved.
Show resolved Hide resolved
searches <https://grep.app/search?q=.add_note%28&filter[lang][0]=Python>`__
did not find any exception classes which define such a method.


How to Teach This
Expand Down Expand Up @@ -202,8 +203,8 @@ or merely significant difficulties working out which explanation corresponds to
which error. The new ``ExceptionGroup`` type intensifies these existing
challenges.

Keeping the ``__notes__`` attached to the exception object, like the
traceback, eliminates these problems.
Keeping the ``__notes__`` attached to the exception object, in the same way as
the ``__traceback__`` attribute, eliminates these problems.


``raise Wrapper(explanation) from err``
Expand Down