I don’t see what this simplifies. We still need to implement split, and to worry about wrapping or not wrapping BaseExceptions and we still need to define exception handling semantics (except/except*).
On 20 Apr 2021, at 22:12, srkunze@mail.de wrote:
So, forgive me my relatively simple mental model about ExceptionGroup. I still try to create one for daily use.
As noted in the discussion, an EG provides a way to collect exceptions from different sources and raise them as a bundle. They have no apparent relation up until this point in time (for whatever reason they have been separate and for whatever reason they are bundled now). The result would be a tree graph in any case.
A usual datastructure for a tree is to store all child nodes at the parent node.
That was the idea behind the content of BaseException.__group__: it’s the list of child exceptions bundled at a specific point in time and raise as such a bundle. So all exceptions could become EGs with the additional semantics you‘ve described in the PEP.
Illustrative Example:
bundle_exc.__group__ [IOError(123), RuntimerError(‘issue somewhere’)]
I was wondering what of the PEP could be removed to make it simpler and more acceptable/less confusing (also looking at reactions from Twitter etc.) and I found these additional classes to be a part of it. Additionally, I fail to see how to access these bundled exceptions in an easy manner like __cause__ and __context__. (As the PEP also referring to them). So, I removed the classes and added a regular attribute.
The reason I brought this up what the section “rejected ideas” didn’t showed anything in this direction (or I managed to missed that).
Sven
On 20. Apr 2021, at 22:05, Irit Katriel <iritkatriel@yahoo.com> wrote:
Hi Sven,
I don’t follow. What would the value of __group__ be and how would it work?
Irit
On 20 Apr 2021, at 20:44, srkunze@mail.de wrote: Hi Irit, reading this subthread specifically, I just got a wild idea and I couldn‘t find any related information in the PEP: Why not extending BaseException by __group__ among __cause__ and __context__? Would this reduce some of the added complexity and thus increase broader acceptance? Cheers, Sven