On Tue, Feb 23, 2021 at 8:00 AM Ivan Pozdeev via Python-Dev < python-dev@python.org> wrote:
> > - In > https://www.python.org/dev/peps/pep-0654/#programming-without-except, > the natural way isn't shown: > > try: > <smth> > except (MultiError, ValueError) as e: > def _handle(e): > if isinstance(e, ValueError): > return None > else: > return exc > MultiError.filter(_handle,e) > > So a statement that the current handling is "cumbersome" and "unintuitive" > is unconvincing. > > If this results in lots of boilerplate code with isinstance(), filter() > can be changed to e.g. accept a dict of exception types and handlers. > Actually, I wonder why you didn't do that already if handling specific > exception types and reraising the rest is the standard procedure! > Then the code would be reduced to: > > try: > <smth> > except (MultiError, ValueError) as e: > MultiError.filter({ValueError: lambda _: None}, > e) > > > - https://github.com/python-trio/trio/issues/611 says that it somehow > causes problems with 3rd-party libraries -- but there's no explanation how > -- either there or in the PEP. > > If some code doesn't know about MultiError's, it should handle one like > any other unknown exception that it cannot do anything intelligent about. > If it wishes to handle them, you need to split MultiError into a separate > library that anyone could use without having to pull the entire `trio`. > I think the main point our PEP tries to make is that having to define a helper function to handle exceptions (and then having to call a utility to call the helper) feels clumsy. However there may be an omission in the PEP -- what if we want to do something special for each suberror? If we just iterate over `eg.errors` we would have to do something recursive for exceptions wrapped inside multiple nested groups. We could add a helper method to ExceptionGroup that iterates over suberrors, flattening nested groups. But we'd need to do something special to recover the tracebacks there (groups share the common part of the traceback). Or we could say "if you need the traceback you're going to have to write something recursive" -- like we have to do in traceback.py. But we might as well generalize whatever we're doing there. (Irit: I suspect there's a piece of API design we missed here.) -- --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/WLGKRP4OQXXW32HXBGG65OEFHZTQTOVQ/ Code of Conduct: http://python.org/psf/codeofconduct/
