Description

jacopoabramo

opened on Jun 18, 2026

Issue body actions

Some time ago I opened a thread on the Python discourse about implementing an AbstractType semantic that would allow functions to receive non-instantiable types so to try and conform a bit the situation presented in the the thread.

Consider the snippet:

from abc import abstractmethod
from typing import runtime_checkable, Protocol, TypeVar, TypeGuard

@runtime_checkable
class MyProtocol(Protocol):
    @abstractmethod
    def my_method(self) -> str:
        ...

class MyClass:
    def my_method(self) -> str:
        return "Hello from MyClass!"
    
class MyOtherClass:
    def another_method(self) -> str:
        return "Hello from MyOtherClass!"
    

P = TypeVar('P', bound=MyProtocol)
    
def check_protocol(obj: object, protocol: type[P]) -> TypeGuard[P]:
    return isinstance(obj, protocol)

# Example usage
my_obj = MyClass()
my_other_obj = MyOtherClass()
if check_protocol(my_obj, MyProtocol):
    print(my_obj.my_method())
if check_protocol(my_other_obj, MyProtocol):
    print(my_other_obj.my_method())
else:
    print("Object does not implement MyProtocol.")

Output:

Hello from MyClass!
my_obj does not implement MyOtherClass protocol.

At runtime, this works as intended. At type checking time, mypy complains that check_protocol cannot accept a non-instantiable type, while pyright and ty are accepting this behavior.

According to the typing specification, mypy is technically correct (the best kind of correct), but this code is perfectly acceptable. There are other examples referenced in python/mypy#4717 (which is the 3rd most upvoted issue by 👍 by the way).

I was hoping for more discussion points presented in the thread but not many replied. I didn't want to monopolize it, so I'm trying my luck here.

@JelleZijlstra (sorry for the ping) did point out that it might be worthwhile to change the spec to allow this behavior but I'm guessing there should be some discussion on how to deal with it first. Jelle suggested: "If you want it to be instantiable, use Callable[] instead."

I do agree it makes sense, but this snippet:

from typing import Protocol

class MyProtocol(Protocol):
    def method(self) -> str:
        ...
print(callable(MyProtocol)) # prints True

confuses me.

So my point is: could the spec allow for type to accept non-instantiable types, since it seems to be a pretty common pattern? Is there a way to effectively deal with the separation between instantiable and non-instantiable types?

I tried adding the "typing spec" label but couldn't. At any rate, thank you for the consideration.

Reacted by Kris Kaczor

Activity

1. jacopoabramo

   added

   topic: otherOther topics not coveredOther topics not covered

   on Jun 18, 2026
2. srittau

   added

   topic: typing specFor improving the typing specFor improving the typing spec

   and removed

   topic: otherOther topics not coveredOther topics not covered

   on Jun 18, 2026
3. davidhalter commented on Jun 18, 2026

   

   davidhalter

   on Jun 18, 2026

   Collaborator

   More actions

   could the spec allow for type to accept non-instantiable types, since it seems to be a pretty common pattern? Is there a way to effectively deal with the separation between instantiable and non-instantiable types?

   I haven't looked into this in detail, but that's exactly the question somebody needs to answer before the spec could be changed. In your specific case the protocol is @runtime_checkable and is therefore not just abstract. My feeling tells me that for this specific case we might be able to relax the spec, but not protocols/abstract types in general. Now that type<some-runtime-checkable-protocol> seems fine, the question is wheter this generalizes beyond guards.

   I think a few more example might help.
4. jacopoabramo commented on Jun 18, 2026

   

   jacopoabramo

   on Jun 18, 2026

   Author

   More actions

   In your specific case the protocol is @runtime_checkable ... My feeling tells me that for this specific case we might be able to relax the spec

   This is perfectly fine. Protocols that aren't marked as runtime checkable shouldn't be used for runtime checks anyway but only for static typing annotations and this is acceptable.

   I think a few more example might help.

   What kind of examples are you looking for exactly? I can do some digging in the github issue I mentioned and copy relevant examples from there if needed.
5. jacopoabramo commented on Jul 13, 2026

   

   jacopoabramo

   on Jul 13, 2026

   Author

   More actions

   I re-read the issue I linked in my initial post to try and find possible other use cases not involving guards, as @davidhalter pointed out.

   1. I was able to find this comment mentioning the usage of protocols for code generation:

   _ProtoT = TypeVar("_ProtoT")
   def with_protocol(proto: Type[_ProtoT]) -> Callable[[type], Type[_ProtoT]]:
       def decorator(cls: type) -> Type[_ProtoT]:
           # some stuff here
           return type(
               cls.__name__ + "_generated",
               (cls, proto),
               generated_methods,
           )
   
       return decorator
   
   
   class Client(Protocol):
      @abstractmethod
      def get_item(self, item_id) -> Item:
         pass
   
   
   @with_protocol(Client):
   class RealClient(SomeBase):
       get_item = get("url here")  # just storing meta information

   2. Another example was this:

   def build(the_type: type[_T], fact: Callable[[], _T] | None) -> _T:
       return the_type() if fact is None else fact()
   
   class Generator(Protocol):
       def __call__(self) -> int: ...
   
   class RandomGenerator:
       def __call__(self) -> int:
           return random.choice(range(100))
   
   gen_obj_good: Generator = RandomGenerator()
   gen_obj_bad: Generator = build(Generator, RandomGenerator) # check fail by `type-abstract`

   I think this usage is wrong. I'm just putting it for completion.

   3. This problem also involves (again, coming from mypy) this usage with attrs:

   @attrs.define(kw_only=True)
   class Schedule:
       ...
       trigger: Trigger = attrs.field(
           eq=False,
           order=False,
           validator=instance_of(Trigger),  # type: ignore[type-abstract]
       )

   I'm only speculating but I'm guessing that Trigger in this context is a Protocol class. Again, this falls into the category of type guarding I supposes.

   4. This comment shows the problem when using dict-dispatching:

   class SomeABC(...): ...
   class DerivedABC1(SomeABC): ...
   class DerivedABC2(SomeABC): ...
   
   map: dict[type[SomeABC], ...] = {
       DerivedABC1: ...,
       DerivedABC2: ...
   }
   print(map[DerivedABC1]) # <-- mypy gives false positive here

   I think that this might be a wider problem than the one I initially proposed.

   ---

   More or less people use ABC and/or Protocol classes as interface types, in order to perform certain actions that go beyond simply creating an object.

   As far as I can tell, type narrowing via isinstance is the primary use case, but given what I read it wouldn't surprise me if protocols might be used for other contexts as well.

   For me, simply allowing protocols marked as runtime_checkable would be an acceptable (initial) trade-off to solve most of the inconsistencies between different type checkers, but then again it still stands that mypy could simply decide not to comply with this change in the specification. That's a decision for their mantainers anyway.

   On how to formalize this... I really don't know.

Issue actions