[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]
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
> On 7. Apr 2021, at 20:26, Irit Katriel via Python-Dev
> wrote:
>
>
> On Mon, Apr 5, 2021 at 2:59 PM Chris Jerdonek
> wrote:
>> This point reminded me again of this issue in the tracker ("Problems with
>> recursive automatic exception chaining" from 2013):
>> https://bugs.python.org/issue18861
>> I'm not sure if it's exactly the same, but you can see that a couple of the
>> later comments there talk about "exception trees" and other types of
>> annotations.
>>
>> If that issue were addressed after ExceptionGroups were introduced, does
>> that mean there would then be two types of exception-related trees layered
>> over each other (e.g. groups of trees, trees of groups, etc)? It makes me
>> wonder if there's a more general tree structure that could accommodate both
>> use cases...
>>
>> --Chris
>
> Interesting, I commented on that issue - I think we may be able to solve it
> without adding more trees.
>
> That said, we will have groups-of-trees/trees-of-groups. Already today, an
> exception plus its chained __cause__s and __context__s is the root of a
> binary tree of exceptions. The nodes of this tree represent the times that
> the exceptions were caught.
>
> An exception group is a tree where the nodes represent the times when
> exceptions were grouped together and raised.
>
> Irit
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@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/BZWELKDUAKCOXSH5KQRFGQJRQWJ2OHKW/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/B7LTPCJIOMTIHO5D3FUZ76DVQDIAMNPY/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]
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 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, srku...@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 ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/4NUG6R36HN557AY36SPINNRFRYBW4QM7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]
Removing two concepts and preserving semantics simplifies the matter for users. People need less to memorize and less to learn. Or am I missing something here? Couldn’t we achieve our goal without these two new classes? Splitting, wrapping and exception handling semantics are perfectly fine and serve their purposes. So, of course this still needs to be implemented. > On 20. Apr 2021, at 23:26, Irit Katriel wrote: > > 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, srku...@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 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, srku...@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 >> ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/OD6IDT5HGDULGLVVQ2HF7WJXNQM7RA3K/ Code of Conduct: http://python.org/psf/codeofconduct/
