Hi Jim,

On Wed, Feb 24, 2021 at 2:16 PM Jim J. Jewett <jimjjewett@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