Hi Petr, Thank you for your careful reading and encouragement.
> The `ExceptionGroup` class is final, i.e., it cannot be subclassed. > > What's the rationale for this? > ExceptionGroup.subgroup()/split() need to create new instances, and subclassing would make that complicated if we want the split results to have the same type. > It is possible to catch the ExceptionGroup type with except, but not > with except* because the latter is ambiguous > > What about `except *(TypeError, ExceptionGroup):`? > Good question. We should block that as well. > > Motivation: Errors in wrapper code > > This use case sticks out a bit: it's the only one where ExceptionGroup > doesn't represent joining equivalent tasks. > Consider code similar to bpo-40857: > > try: > with TemporaryDirectory() as tempdir: > os.rmdir(tempdir) > n = 1 / 0 > except ArithmeticError: > # that error can be safely ignored! > pass > > Instead of a FileNotFoundError with ArithmeticError for context you'd > now get an ExceptionGroup. Neither is handled by `except > ArithmeticError`. Where is the win? > I agree, if TemporaryDirectory() were ever to adopt ExceptionGroups then it will probably be through a new API (like an opt-in parameter) to avoid breaking current code. Users of such a TemporaryDirectory would need to wrap the calls with try-except* (see the example in my previous reply to Steve). > > Motivation: Multiple failures when retrying an operation > > This is somewhat similar to the TemporaryDirectory, except there's no > `with` block that feels like it should be "transparent" w.r.t. user errors. > If I currently have: > > try: > create_connection(*addresses) > except (Timeout, NetworkNotConnected): > # that's OK, let's try later > pass > > what should happen after Python 3.10? Apart from adding a new function, > I can see two possible changes: > - create_connection() starts always raising ExceptionGroup on error, > breaking backwards compatibility in the error case > - create_connection() starts only raising ExceptionGroup only for 2+ > errors, breaking backwards compatibility in the 2+ errors case > Both look like heisenbug magnets. IMO, the second one is worse; "code > which is now *potentially* raising ExceptionGroup" (as mentioned in the > Backwards Compatibility section; emphasis mine) should be discouraged. > > Arguably, this here is a problem with the create_connection function: > the PEP adds a better way how it could have been designed, and that is > virtuous. Still, having it in Motivation might be misleading. > I agree. Raising ExceptionGroups is an API breaking change, for any library. No function should just start raising ExceptionGroups. > long term plan to replace `except` by `catch` > > Whoa! Is that a real plan? > In the rejected ideas section, anything goes! 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/R7ONTCH5MUWKBOPHY2QYKVNPOT5MXPYZ/ Code of Conduct: http://python.org/psf/codeofconduct/
