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-t... 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