On Wed, Mar 3, 2021 at 11:26 AM Irit Katriel via Python-Dev < python-dev@python.org> wrote:
> > > On Wed, Mar 3, 2021 at 6:57 PM Paul Moore <p.f.mo...@gmail.com> wrote: > >> Sorry, I keep thinking I've finished and you keep making interesting >> points :-) >> >> On Wed, 3 Mar 2021 at 17:01, Irit Katriel <iritkatr...@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. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
_______________________________________________ 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/4DDHVB3VSWEKPZABKO5C3LDFCPTQKRIN/ Code of Conduct: http://python.org/psf/codeofconduct/
