I'd like to understand what benefit `@sealed` has over defining an explicit union type that contains the classes that comprise the exhaustiveness set. The linked PEP says that the union approach is "fragile". I use this technique extensively, and I find it anything bug fragile. It's incredibly robust, easy to maintain, and easy to understand. It also works well with today's type system and type checkers. I'm very negative on the idea of adding `@sealed` to the type system. It would represent the first (and so far only) place where semantics of a type depend on the module in which it is declared. Such a construct would be an exceptional case in the type system and would be problematic for for lazy type evaluators like pyright, which evaluate types of individual symbols on demand rather than analyzing entire files. -Eric -- Eric Traut Contributor to pyright & pylance