On Sun, Apr 17, 2022 at 12:46 PM Jelle Zijlstra <jelle.zijlstra@gmail.com> wrote:
El sáb, 16 abr 2022 a las 13:47, John Hagen (<johnthagen@gmail.com>) escribió:
Yes, this would need to be a new PEP. I'd probably be willing to sponsor such a PEP.
Thanks Jelle. I will try to put a PEP together, likely pulling heavily from the section already written in PEP 622.
Looking at that section again, I noticed a problem with the spec at https://peps.python.org/pep-0622/#sealed-classes-as-algebraic-data-types. Given a class hierarchy with `Node` as the base class and a number of leaf classes, it says "With such definition, a type checker can safely treat Node as Union[Name, Operation, Assignment, Print]". But there is nothing in the code sample that tells a type checker that an object of type `Node` can't be an instance of the base class. Presumably you could use `abc.ABCMeta` to indicate that the base class is abstract, but that may be disruptive at runtime, because it requires using a metaclass.
Type checkers could probably just treat the base class of a sealed class as implicitly abstract. (Just as they would treat every subclass as `@final` outside the module.)
Eric's feedback is also important to consider. What compelling benefit does this new type system feature provide over just using a Union?
Perhaps nothing other than the convenience of not having to repeat the class names in the definition of the union (at the cost of having to define the base class, adorn it with `@sealed`, and repeating that as the base class for all the case classes). I also agree with Eric that it feels awkward to require that all the case classes must be defined in the same file -- this violates a general refactoring principle. Though maybe it's okay (just like all methods of a class must be defined in the same file). -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>