diff --git a/pep-0654.rst b/pep-0654.rst index 23c7a86ef5d..656e92e0b95 100644 --- a/pep-0654.rst +++ b/pep-0654.rst @@ -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. 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`` ------------------------------------------------ @@ -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 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