We have the @final decorator to mark a class as final, so that it cannot be subclassed. Typecheckers can then cue off of this to raise an error when there are unimplemented abstract methods (e.g. the Ty abstract-method-in-final-class rule).
Similarly, Pyright and Ty can flag errors when other code instantiates a class that has abstract methods.
However, I would find it very useful to be able to mark a class as concrete: it isn't final (someone might subclass it), but it is intended to be instantiable. This would allow the type checker to raise abstract method errors at the point of class definition, rather than elsewhere in the code where the class is instantiated. For classes that are instantiated directly, the error location isn't a huge problem; for classes that are primarily instantiated indirectly, however, it there is no guarantee that the code will include a direct instantiation of the class to raise an error.
We have the
@finaldecorator to mark a class as final, so that it cannot be subclassed. Typecheckers can then cue off of this to raise an error when there are unimplemented abstract methods (e.g. the Ty abstract-method-in-final-class rule).Similarly, Pyright and Ty can flag errors when other code instantiates a class that has abstract methods.
However, I would find it very useful to be able to mark a class as concrete: it isn't final (someone might subclass it), but it is intended to be instantiable. This would allow the type checker to raise abstract method errors at the point of class definition, rather than elsewhere in the code where the class is instantiated. For classes that are instantiated directly, the error location isn't a huge problem; for classes that are primarily instantiated indirectly, however, it there is no guarantee that the code will include a direct instantiation of the class to raise an error.