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.

Sign up for GitHub

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-654: add mention of the 'Flat EG' proposal to the rejected ideas … #2104

Merged
merged 1 commit into from
Oct 19, 2021
Merged

PEP-654: add mention of the 'Flat EG' proposal to the rejected ideas … #2104

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
13 changes: 11 additions & 2 deletions pep-0654.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1178,7 +1178,8 @@ Furthermore, as we explained in the `Handling Exception Groups`_ section, we
find it unlikely that iteration over leaf exceptions will have many use cases.
We did, however, provide there the code for a traversal algorithm that
correctly constructs each leaf exceptions' metadata. If it does turn out to
be useful in practice, we can add that utility to the standard library.
be useful in practice, we can in the future add that utility to the standard
library or even make exception groups iterable.

Make ``ExceptionGroup`` Extend ``BaseException``
------------------------------------------------
Expand Down Expand Up @@ -1250,10 +1251,18 @@ clauses with the knowledge that they are only executed once. If there is
a non-idempotent operation there, such as releasing a resource, the
repetition could be harmful.

The idea of making ``except`` iterate over the leaf exceptions of an exception
group is at the heart of an `alternative proposal to this PEP by Nathaniel J. Smith
<https://discuss.python.org/t/flat-exception-groups-alternative-to-pep-654/10433>`_,
and the discussion about that proposal further elaborates on the pitfalls of
changing ``except`` semantics in a mature language like Python, as well as
deviating from the semantics that parallel constructs have in other languages.

Another option that came up in the public discussion was to add ``except*``,
but also make ``except`` treat ``ExceptionGroups`` as a special case.
``except`` would then do something along the lines of extracting one exception
of matching type from the group in order to handle it. The motivation behind
of matching type from the group in order to handle it (while discarding all
the other exceptions in the group). The motivation behind
these suggestions was to make the adoption of exception groups safer, in that
``except T`` catches ``Ts`` that are wrapped in exception groups. We decided
that such an approach adds considerable complexity to the semantics of the
Expand Down