Sorry, I keep thinking I've finished and you keep making interesting points :-)
On Wed, 3 Mar 2021 at 17:01, Irit Katriel <iritkatriel@googlemail.com> wrote:
> Raising an ExceptionGroup is an API change. If you call APIs that say they will raise ExceptionGroups you need to update your code accordingly. If a library doesn't document that it raises ExceptionGroups and then one of those escapes, then that library has a bug. Just like with any other exception type.
In my experience, libraries don't document what exceptions they raise
very well. You can call that a bug, but it's a fact of life, I'm
afraid. The problem here isn't so much that the library code now
raises an exception that it used not to raise, but rather that *the
user hitting Ctrl-C* can now result in a different exception surfacing
in my code than it used to. Libraries don't re-wrap KeyboardInterrupt,
as you pointed out in a previous response, so I can currently write
code that traps KeyboardInterrupt, safe in the knowledge that by doing
so I'll handle that user action properly. But with PEP 654, libraries
might well (indeed, some libraries almost certainly will) start
wrapping KeyboardInterrupt in an exception group. That's a backward
incompatible change from the perspective of my code's interaction with
the user, and I need to re-code my application to deal with it (and
worse still, writing that new code in a way that is portable between
versions is not particularly straightforward).
This is also true for MemoryError, and many other errors. What makes KeyboardInterrupt special?
Users get really grumpy if they can't stop a runaway program with ^C -- they want it to either terminate the script or app, or go back into the toplevel REPL if there is one. And users write runaway code all the time.
asyncio in particular catches BaseException but excludes (reraises) KeyboardInterrupt and SystemExit.
OTOH MemoryError is rarely a problem -- and Linux for example kills the process rather than failing to allocate more memory, so you won't even get an exception, so how it's treated by the exception machinery doesn't matter. The MemoryErrors you do get tend to be recoverable, as in 'x'*1000000000000.
--