Assignability to a Protocol Using `Self` Must Respect Variance

Abierto
#2,051 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
38/100
Tipo de issue
Documentación
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
python
Área
documentation

Línea de trabajo

Comienza con docs/spec/generics.rst en las líneas enlazadas 2540-2544 y revisa la discusión circundante sobre Self en los protocolos. Ejecuta los ejemplos proporcionados con mypy y pyright, y después actualiza el párrafo y el ejemplo cercano para explicar los usos contravariantes, covariantes e invariantes de Self; se considerará terminado cuando la especificación coincida con el comportamiento demostrado por los analizadores.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

topic: typing spec

I just stumbled across this paragraph:

https://github.com/python/typing/blob/2d88da2a407b556f5b52b4c6ad1bd659873bb9ac/docs/spec/generics.rst?plain=1#L2540-L2544

If I understand it correctly, then the following code is fine, i.e., Foo is assignable to Proto according to the explanation:

from __future__ import annotations

from typing import Protocol, Self


class Proto(Protocol):
    def f(self, x: Self) -> None: ...


class Foo:
    def f(self, x: Sub) -> None:
        pass


class Sub(Foo):
    pass


x: Proto = Foo()

However, type checkers like mypy and pyright reject this code. This aligns with my expectation: If I have an instance x: Proto, then I should be able to call x.f(x). But for y: Foo, I cannot call y.f(y).

The paragraph in question should distinguish between covariant, contravariant, and invariant occurences of Self:

from __future__ import annotations

from typing import Protocol, Self


class Proto(Protocol):
    def f(self, x: Self) -> None: ...  # contravariant
    def g(self, x: Self) -> Self: ...  # x: contravariant, return type: covariant
    def h(self, x: list[Self]) -> None: ...  # invariant


class Sup:
    pass


class Foo(Sup):
    def f(self, x: Sup) -> None:  # x can be of type Foo or any superclass
        pass

    def g(self, x: Sup) -> Sub:  # return type can be Foo or any subclass
        raise RuntimeError()

    def h(self, x: list[Foo]) -> None:  # no sub-/superclass allowed as argument to list
        pass


class Sub(Foo):
    pass


x: Proto = Foo()  # OK, also according to mypy and pyright

I assume that all the uses of Self are valid in this example, at least mypy and pyright do not complain and I couldn’t find any statement that would restrict Self in protocols to covariant positions or even return types only. Maybe it also makes sense to adjust the example after the paragraph in question. Currently, it only uses Self in a return type.

Lenguaje dominante
Python
Estrellas
1.8k
Forks
302
Merge medio
23 h
PR fusionados (30 d)
8

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de python/typing

Todos los issues de python/typing

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.