On Sat, 27 Mar 2021, 9:24 am Guido van Rossum, <guido@python.org> wrote:
Everyone,

Given the resounding silence I'm inclined to submit this to the Steering Council. While I'm technically a co-author, Irit has done almost all the work, and she's done a great job. If there are no further issues I'll send this SC-wards on Monday.

+1 from me. I remember talking to Nathaniel (and Yury IIRC) about early iterations of the MultiError handling in trio at PyCon years ago, so it's great to see the way the concept has matured in the intervening time.

The one thing I did think was that it might be good to mention concurrent.futures and contextlib in the PEP as modules that could potentially take advantage of exception groups. I'm not sure it's really necessary though, as the presentation is already compelling as it is.

Cheers,
Nick.

P.S. The potential use case I see in contextlib: the way ExitStack nests dynamic resource handling *works*, but the tracebacks when multiple clean up steps fail can be spectacularly cryptic. With exception groups available, it should be possible to define a new "context lib.ExitGroup" API that flattens out the resource clean up and collects any exceptions that occur into a more comprehensible exception group, rather than building a nested exception context tree the way ExitStack does.




--Guido

On Sat, Mar 20, 2021 at 10:05 AM Irit Katriel <iritkatriel@googlemail.com> wrote:

We would like to present for feedback a new version of PEP 654, which incorporates the feedback we received in the discussions so far:
The reference implementation has also been updated along with the PEP.

The changes we made since the first post are:

1. Instead of ExceptionGroup(BaseException), we will have two new builtin types: BaseExceptionGroup(BaseException) and ExceptionGroup(BaseExceptionGroup, Exception).
This is so that "except Exception" catches ExceptionGroups (but not BaseExceptionGroups). BaseExceptionGroup.__new__ inspects the wrapped exceptions, and if they are all Exception subclasses, it creates an ExceptionGroup instead of a BaseExceptionGroup.  

2. The exception group classes are not final - they can be subclassed and split()/subgroup() work correctly if the subclass overrides the derive() instance method as described here: https://www.python.org/dev/peps/pep-0654/#subclassing-exception-groups

3. We had some good suggestions on formatting exception groups, which we have implemented as you can see in the output shown for the examples in the PEP.

4. We expanded the section on handling Exception Groups, to show how subgroup can be used (with side effects) to do something for each leaf exception, and how to iterate correctly when the tracebacks of leaf exceptions are needed: https://www.python.org/dev/peps/pep-0654/#handling-exception-groups

5. We expanded the sections on rationale and backwards compatibility to explain our premise and expectations regarding how exception groups will be used and how the transition to using them will be managed.

6. We added several items to the rejected ideas section.

We did not receive any comments (or make any changes) to the proposed semantics of except*, hopefully this is because everyone thought they are sensible.

Irit, Yury and Guido



--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/AQGDIZDZOJDR4HNRYCJVFA2XJ7YOOXS5/
Code of Conduct: http://python.org/psf/codeofconduct/