Open ilevkivskyi opened 4 years ago
Would this @sealed
decorator not be a prime candidate to put into the utilities module #23?
It seems (other than for static type checkers) this has little influence on the match statements we are proposing. As the decorator has no effect within Python itself and is not mandatory, I do not see any reason to be against its introduction.
Can we mark this issue as accepted? Sorry if I'm playing project manager here (not my usual role, I assure you :))
Also, I wonder to what extent @typing.sealed can be used as an optimization hint: for example, if we know that the set of match patterns are distinct and non-overlapping, then I can see how you might be able to pre-generate a discrimination tree or possibly even a dispatch table (assuming no-one re-binds the names, not sure how you would get around that.)
Bike shed: tying.sealed or matching_utils.sealed?
That optimization seems really advanced, we’re going to have our hands full just getting it to work.
I propose to add a
@typing.sealed
class decorator that would do nothing at runtime, but indicate to static type checkers that all subclases must be defined in the same module. This will allow static checkers interpret such class as a union of all their children, so they can do static exhaustiveness checks. Effectively sealed classes together with dataclasses would provide nice support for algebraic data types pattern. See this (rather long) example: