Beyond the annoyance of multiple imports, there's also the potential issue of non-Union subclasses of BaseCoin. I've used this pattern a few times, and it works alright, but it feels inelegant to have 2 types that conceptually represent the same point in the type hierarchy, and can create confusing when trying to use one in an invalid way. It also creates an opportunity for those points to, unintentionally diverge. That being said, I'm not a huge fan of the `sealed` decorator suggestion. It seems like it would be easy to miss when refractoring or adding classes. I think I'd prefer something like: ``` class Tree(Sealed[Node, Leaf]): ... class Node(Tree): ... class Leaf(Tree):. ``` To keep the anticipated sub classes specific, and work more similarly to `abc.ABC` Or, if something more implicit through location is desired, to avoid repetition, then at least a shared indentation would be clearer: ``` with sealed('Tree'): class Tree: ... class Node(Tree): ... class Leaf(Tree):... ``` (Just to illustrate the idea, I'm sure there's a better representation) But I'm not convinced the relatively limited repetition is sufficiently compelling. On Tue, 19 Apr 2022, 01:17 David Hagen, <david@drhagen.com> wrote:
If all of the classes in the union derive from the same base class, you can use the base class for the `isinstance` check or case statement.
You're not wrong, but I would consider it quite annoying to have to import both Coin and BaseCoin in order to use this ADT. Conceptually, they are the same thing split into two. If this became standard, I think Python would be the first programming language in which the base class of an ADT and the type of the ADT were distinct names and objects. _______________________________________________ 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: diabolo.dan@gmail.com