Draft PEP: Sealed decorator for static typing

[hlovatt (Howard Lovatt)]

@alicederyn

This whole idea is based around supporting algebraic data types, but it only lets you support one algebraic data type for any given class, and worse, you have to own that class! What if you want to reuse that class in another type with a different set of members? You can’t.

I have a different take on this:

1. I want runtime enforcement so that I don’t have to use typing if I don’t want to. I like optional typing, not mandatory typing. Yes I know this thread is about static typing, but I want to widen the debate to be about sealed in general.
2. It’s easy to allow a type to participate in many hierarchies:

from some_module import Node

@sealed('<class0>, ...)
class MyNode(Node): ...

I like this construct; if Node is designed to take part in many hierarchies then it won’t be sealed and can be used in many hierarchies, but I can seal my version for my own purposes.

[alicederyn (Alice)]

@mikeshardmind

Ordered intersections should be seen as completely separate from ADTs. Python’s union type is not a sum type, and even if it were, intersections would not help with what is proposed here.

This wasn’t the question asked. It got lost in the thread, but the question was, could ordered intersection be used to create a type equivalent to a union to a type checker but with static methods available at runtime.

[mikeshardmind (Michael H)]

You could do something along those lines, but it would be more complicated and still require that at runtime those static methods come from somewhere and exist on each of the possible types in the union… which sounds like the right answer is just put that on the base class.

[mikeshardmind (Michael H)]

@drhagen

Obviously, there are alternative designs than @sealed that fulfill the role of a nominal sum type in Python (e.g. @enum, __sealed__ = A|B, class X() of A|B: etc.), but that there is a hole here to be filled that complements Union rather than supplants it.

I’m not sure I see the case for ADTs in python. I expressed some of this in the thread relating to Union support for __match_args__, but something I’d need to see is how this improves use at runtime, not just for typing. If it’s just for static typing, there are existing methods like:

@alicederyn

@final
class TagA(NamedTuple):
  a: TypeA

@final
class TagB(NamedTuple):
  b: TypeB

TaggedUnion = TagA | TagB

I’d also need things to be reusable and composable. I don’t think any iteration of a sealed type does this well, including the decorators that require specifying the allowed types they wrap as forward references.

Right now, the closest things in the standard library are enums and data classes

I’m not saying it belongs in enum, but something that worked in a similar manner

class SomeADT(enum.ADT)
    A: TypeA
    B: TypeB

instb = TypeB()
b = SomeADT(instb)  # SomeADT.B
b.value # instb

seems much more likely to be able to gain wider support as it would work at runtime, wouldn’t mix sealed types with ADTs, It might also be easier to demonstrate some of the harder problems that people have with the status quo if you arent’ demonstrating it with something that makes it easy for someone to say “just use a union” by showing runtime capability with static inference possible

[hlovatt (Howard Lovatt)]

@mikeshardmind

I’m not saying it belongs in enum, but something that worked in a similar manner

The version of sealed, that I have posted above, I think would sit very well in the enum module (not Enum itself)! As would other variants of sealed, so long as they were runtime enforced.