I appreciate the work that went into the proposal, but I'm strongly negative on adding `@sealed` to the Python type system for the reasons I mentioned previously in this thread. It creates new problems by introducing the first and only case where type behavior is dependent on the module in which the type is declared. The use of unions with a separate base class is discussed in the "Rejected Ideas" section, but I find the argument extremely weak.
Despite being possible today, this is quite unergonomic.
The notion of "unergonomic" is subjective, but this doesn't look at all unergonomic to me. Once you know about the pattern, it's easy to use and understand. If you haven't seen it before, it might look odd initially, but the same is true for `@sealed`. And `@sealed` requires understanding new concepts within the type system, whereas Python users (and existing Python tools) already understand the concept of base classes and unions.
If this became standard, it seems Python would be first language to separate the definition of an ADT into two different objects.
That's not true. TypeScript (which is way more prevalent than Kotlin and Scala) takes this approach. IMO, this would be a net negative contribution to the type system. It would be much cheaper to document and evangelize the technique that uses a base class and unions. -Eric