iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PEP-654: add mention of the 'Flat EG' proposal to the rejected ideas section (GH-2104)

This commit is contained in:
Irit Katriel 2021-10-19 23:15:45 +01:00 committed by GitHub
parent 401d207bd3
commit 859b31cd4a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 11 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
pep-0654.rst
View File

@ -1183,7 +1183,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. 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 We did, however, provide there the code for a traversal algorithm that
correctly constructs each leaf exceptions' metadata. If it does turn out to 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`` Make ``ExceptionGroup`` Extend ``BaseException``
------------------------------------------------ ------------------------------------------------
@ -1255,10 +1256,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 a non-idempotent operation there, such as releasing a resource, the
repetition could be harmful. 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*``, Another option that came up in the public discussion was to add ``except*``,
but also make ``except`` treat ``ExceptionGroups`` as a special case. but also make ``except`` treat ``ExceptionGroups`` as a special case.
``except`` would then do something along the lines of extracting one exception ``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 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 ``except T`` catches ``Ts`` that are wrapped in exception groups. We decided
that such an approach adds considerable complexity to the semantics of the that such an approach adds considerable complexity to the semantics of the