Just to add +1 for Paul's concerns.
 
Even though ExceptionGroups "are not supposed" to not
leak into caller code, don't mean they "won't". Making  "except Exception"
catch them would make this part a non issue, and the
feature looks great otherwise.

On Wed, 3 Mar 2021 at 13:44, Paul Moore <p.f.moore@gmail.com> wrote:
On Wed, 3 Mar 2021 at 14:59, Irit Katriel <iritkatriel@googlemail.com> wrote:
>> 2. Given the above, why even have a means of grouping BaseExceptions
>> at all? Why not just have ExceptionGroup that can only catch instances
>> of Exception?
>
> Because the IGotInterrupted alternative involves wrapping a BaseException by an Exception, which is not something we should push people into doing (it's not that different from allowing ExceptionGroup to wrap BaseExceptions directly).

That's a fair point.

> What's the harm/complication in offering a BaseExceptionGroup(BaseException) in addition to ExceptionGroup(BaseExceptionGroup, Exception)?

Similar to the argument for "except Exception". Applications that trap
KeyboardInterrupt so that they can exit cleanly without an ugly
traceback will no longer trap *all* keyboard interrupts, as they could
miss grouped ones.

If we accept that grouped exceptions should never escape out of a
well-defined context, then this wouldn't be such an issue. But there's
nothing in the PEP that enforces that, and there *is* code that needs
to be prepared for "any sort of result". It's the except Exception
argument again.

So code that wants to exit cleanly in the face of Ctrl-C will need to
be rewritten from:

try:
    main()
except KeyboardInterrupt:
    print("User interrupted the program. Exiting")
    sys.exit(1)

to:

try:
    try:
        main()
    except KeyboardInterrupt:
        print("User interrupted the program. Exiting")
        sys.exit(1)
except *KeyboardInterrupt:
    print("User interrupted the program. Exiting")
    sys.exit(1)

Did I miss an easier way of writing this code? And worse, how would I
write it so that it was portable between Python 3.9 and later versions
(which is a common requirement for library code - admittedly library
code wouldn't normally be doing this sort of top-level trap, but it
could just as easily be "catch Ctrl-C and do a bit of tidy-up and
re-raise").

> I think the only reason you're comfortable with having to select between the exceptions that were raised and discard some of them is because that's where we are today. The PEP lists several standard library and other APIs that discard errors because they need to pick one. That's what we're trying to fix.

Maybe. But I'm not looking at it as being "comfortable" with the
current situation, but rather as "I don't use any of these new
features, why am I having to change my code to accommodate stuff I
don't use?" If I own the full stack, that's not an issue, but
frameworks and libraries typically have to interact with other users'
code, and there the contract has changed from "do what you like in
your code and I'll cope" to "do what you like in your code as long as
you don't let an exception group escape, and I'll cope"... And I have
to change *my* code to get the old contract back.

But it's a small point in the wider scheme of things, and I'm not
going to labour the point any more. Thanks for listening and taking
the time to reply.

Paul

Paul
_______________________________________________
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/WSUEOGDCBBOZ7PCQGUCXKIZEZ7RK34LK/
Code of Conduct: http://python.org/psf/codeofconduct/