Draft PEP: Sealed decorator for static typing

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.

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.

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.

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:

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

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.