See also this section of PEP 622 (Structural Pattern Matching), which proposed a `@sealed` class decorator:

https://www.python.org/dev/peps/pep-0622/#sealed-classes-as-algebraic-data-types

To avoid losing focus, that whole static typing section was dropped when the proposal was rewritten as PEPs 634, 635, and 636. I would definitely support one or more PEPs that formalize the static typing behavior of match statements and reintroduce sealed classes.

I'm still undecided on runtime-validation and decoration vs. inheritance, though... are there potential use-cases where inheritance wouldn't be possible, or where we wouldn't actually want runtime-validation?

If we go the ABC route, it may make more sense to check `isinstance(c, Sealed)` instead of `Sealed in c.__bases__`. That would allow imported classes (perhaps from C extensions) to be later registered as sealed. We could even go so far as to define `sealed = Sealed.register` if we wanted to use decoration instead of inheritance.

Brandt
_______________________________________________
Typing-sig mailing list -- typing-sig@python.org
To unsubscribe send an email to typing-sig-leave@python.org
https://mail.python.org/mailman3/lists/typing-sig.python.org/
Member address: guido@python.org