Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Relaxing usage of `type` with `typing.Protocol` in typing spec

Offen
  • Stimmt etwas nicht?
#2,306 3 Kommentare 1 Reaktion 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
35/100
Issue-Typ
Feature
Klarheit
Muss geklärt werden
Aktivitätsstatus
Ruhig
Tech-Stack
python
Bereich
documentation

Rechercherichtung

Beginne mit der Diskussion zur Typing-Spezifikation und dem verlinkten Python-Discourse-Thread und vergleiche anschließend das für mypy, pyright und ty beschriebene Verhalten. Sieh dir mypy#4717 auf verwandte Beispiele hin an. Als abgeschlossen gilt die Einigung darüber, ob type[P] nicht instanziierbare Protocol-Typen akzeptieren darf, sowie die Dokumentation der daraus resultierenden Regel.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

topic: typing spec

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.

Vorherrschende Sprache
Python
Sterne
1.8k
Forks
302
Ø Merge
20 Std. 26 Min.
Gemergte PRs (30 T.)
10

Entwicklungsumgebung

Die Einrichtungsdateien dieses Projekts haben wir noch nicht geprüft. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus python/typing

Alle Issues in python/typing

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.