From c5887a26b2e68b204e311d352dbb3b939a929e30 Mon Sep 17 00:00:00 2001 From: Irit Katriel Date: Thu, 7 Oct 2021 15:57:55 +0100 Subject: [PATCH] PEP-654: add mention of the 'Flat EG' proposal to the rejected ideas section --- pep-0654.rst | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/pep-0654.rst b/pep-0654.rst index 2d47e5261a3..c20e4837bab 100644 --- a/pep-0654.rst +++ b/pep-0654.rst @@ -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`` ------------------------------------------------ @@ -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 +`_, +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