Reason given for disallowing non-concrete subtype assignment is unsound
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/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 la sección enlazada «type-and-class-objects-vs-protocols» en docs/spec/protocol.rst y, después, lee la typing discussion enlazada y el mypy issue para conocer la justificación relacionada. El issue presenta direcciones contrapuestas en lugar de un cambio definido; el trabajo estaría terminado cuando se haya acordado una decisión sobre la especificación y, posteriormente, se actualicen la justificación y los ejemplos asociados.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Issue
According to the discussion https://github.com/python/typing/discussions/1305, “type checkers allow incompatible __init__ overrides, because flagging them would be too disruptive.”
Accepting above as de facto, the example given as the main reason for disallowing non-concrete subtype assignment in the following section of the spec is unsound:
https://github.com/python/typing/blob/e08290b70f58df509f998cbbe09a8e65abb57a9b/docs/spec/protocol.rst#type-and-class-objects-vs-protocols
class Proto(Protocol):
@abstractmethod
def meth(self) -> int:
...
class Concrete:
def meth(self) -> int:
return 42
def fun(cls: type[Proto]) -> int:
return cls().meth() # ???
fun(Proto) # Why should this error?
fun(Concrete) # OK
var: Type[Proto]
var = Proto # Why should this error?
var = Concrete # OK
var().meth() # ???
(credit https://github.com/python/mypy/issues/4717#issuecomment-1978239641 for pointing out the contradiction)
Thoughts
One radical approach would be to remove the concreteness rule from the spec altogether. The type of Proto is type[Proto], and if the constructor compatibility is not checked, there is little reason to disallow it from being assigned to variables annotated as type[Proto].
If that is too radical, the spec can stay as is but the reasoning and associated examples should be clearly marked ‘historical’ and no longer valid. That way, we can avoid any immediate changes in practice, but at the same time encourage discussions towards appropriate future specs.
- 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
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de python/typing
-
topic: typing spec
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
-
topic: typing spec
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
topic: documentation
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
-
topic: documentation
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
-
topic: conformance tests topic: typing spec
Dificultad 3/5 1-2 días Aptitud para principiantes 72/100
Todos los issues de python/typing
Issues similares
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
canonical/paas-charm#368 · 1 comentario ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
tech debt
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
addition to tracking list Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
StevenBlack/hosts#3256 ·
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
qualcomm/qai-appbuilder#275 ·