Hi Jim, On Wed, Feb 24, 2021 at 2:16 PM Jim J. Jewett <jimjjew...@gmail.com> wrote:
> Petr: What about except *(TypeError, ExceptionGroup):? > > Irit: Good question. We should block that as well. > > But https://www.python.org/dev/peps/pep-0654/#backwards-compatibility > seems to explicitly recommend the very similar: > > except (Exception, ExceptionGroup): That's except, not except*. Please include an example for: > > except *ExceptionGroup: pass > There is one here: https://www.python.org/dev/peps/pep-0654/#forbidden-combinations It raises a Runtime Error. The "no subclasses" seems pretty severe, particularly if you can't even use > marker attributes because it isn't clear when a different instance of > container ExceptionGroup will be substituted. > > The justification for this restriction was that .split() had to be be able > to instantiate ... wouldn't it be enough to just say that subclasses need a > compatible __init__ and __new__ for that reason, and then leave it to > consenting adults? What do you mean by compatible? How would one's marker attributes be copied to the new instances? split() currently copies (context, cause, traceback) from the original ExceptionGroup to the new ones. We could have some protocol, but I'm not sure what it would look like. I'm pretty sure there will be a cost, and I'm not sure I understand why no subclassing is a serious enough limitation to justify that. 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/NMJSQW5D6O43KMLMOHY6X6Z2PXT5XYFB/ Code of Conduct: http://python.org/psf/codeofconduct/
