python / python/typing

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

Aperta
#2,306 3 commenti 1 reazione 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

topic: typing spec
Lingua principale
Python
Stelle
1.8k
Fork
302
Merge medio
23h
PR unite (30g)
8

Descrizione

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.

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Direzione di ricerca

Inizia dalla discussione sulla specifica di typing e dal thread di Python Discourse collegato, quindi confronta il comportamento descritto per mypy, pyright e ty. Esamina mypy#4717 per esempi correlati. Il lavoro è completato quando si raggiunge un accordo sul fatto che type[P] possa accettare tipi Protocol non istanziabili e si documenta la regola risultante.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Valutazione

Stack tecnologico
python
Ambito
documentation
Tipo di issue
Funzionalità
Difficoltà
5/5
Tempo stimato
Più di una settimana
Stato di attività
Tranquilla
Chiarezza
Da chiarire
Idoneità per principianti
35/100

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.