On Sat, 27 Feb 2021 at 00:35, Guido van Rossum <gu...@python.org> wrote: > On Fri, Feb 26, 2021 at 3:18 PM Marco Sulla <marco.sulla.pyt...@gmail.com> > wrote: >> >> Excuse me if I post here. Maybe is a stupid question: why, instead of >> introducing except*, Python can't extend the functionality of except, >> so it can do what except* would do? > > > Good question. Here's an example: > ``` > try: > . . . > except OSError as err: > if err.errno != ENOENT: > raise > . . . > ``` > If this would catch ExceptionGroup(OSError), the `err` variable would be an > ExceptionGroup instance, which does not have an `errno` attribute.
Thank you for the clarification :) I must admit I read the PEP quickly, so I thought that the subexception will be raised by except*, not the exception group. But obviously this can't work. The fact is I am really used to think that except OsError as e means "except for any OsError, which we name `e` from this moment on" that I thought it applied also for except*. But, if I understood well except* OsError as eg means "except for any OsError contained in an ExceptionGroup. If the OsError is not contained in an ExceptionGroup, Python wraps it in a new ExceptionGroup. The ExceptionGroup is named `eg` from this moment on" I have to say that it's not obvious for me reading except* this way. Anyway, I can't find a more readable semantic that does not use a new keyword and it's short ^^' _______________________________________________ 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/XZRM57YQU3NRU5JLAHDULVR7TKUF5FT3/ Code of Conduct: http://python.org/psf/codeofconduct/
