Error code for subclassing final #4483

Activity

1. Avasam (Avasam)

   added

   enhancement requestNew feature or requestNew feature or request

   on Jan 18, 2023
2. erictraut commented on Jan 18, 2023

   

   Eric Traut (erictraut)

   on Jan 18, 2023

   Collaborator

   More actions

   Pyright doesn't support error codes. It supports diagnostic checks which have names like reportUnusedVariable, etc. I don't think it makes sense to create a new diagnostic check specifically for subclassing of final types. A @final class decorator has a very specific and well-defined meaning, and I would recommend against ever attempting to subclass a final class because it will break many other assumptions and checks in a static type checker.

   👍React with 👍1Reacted by Avasam
3. Eric Traut (erictraut)

   added

   as designedNot a bug, working as intendedNot a bug, working as intended

   on Jan 18, 2023
4. Eric Traut (erictraut)

   closed this as completedon Jan 18, 2023
5. AlexWaygood commented on Jan 18, 2023

   

   Alex Waygood (AlexWaygood)

   on Jan 18, 2023

   Last edited by AlexWaygood

   More actions

   For additional context: the reason why we very occasionally subclass @final classes in typeshed is to account for situations like this, where classes cannot be subclassed in pure Python but nonetheless have real, existing subclasses in the stdlib:

   >>> dict_keys = type({}.keys())
   >>> dict_keys
   <class 'dict_keys'>
   >>> class Foo(dict_keys): ...
   ... 
   Traceback (most recent call last):
     File "<string>", line 1, in <module>
   TypeError: type 'dict_keys' is not an acceptable base type
   >>> from collections import OrderedDict
   >>> type(OrderedDict().keys())
   <class 'odict_keys'>
   >>> _.__mro__
   (<class 'odict_keys'>, <class 'dict_keys'>, <class 'object'>)

   When writing a stub for dict_keys, the only logical thing to do is to mark it with @final in the stub, since it cannot be subclassed in pure Python. But that means we have to pyright: ignore our stub for collections.odict_keys, since the odict_keys class subclasses a @final class.

   I appreciate that this is a pretty unusual use case, however, so it's fine to leave this as a wontfix if you don't think it's worth it.

   👍React with 👍1Reacted by Avasam