Reason given for disallowing non-concrete subtype assignment is unsound
Personne n'a encore pris cette issue.
- Langage dominant
- Python
- Étoiles
- 1.8k
- Forks
- 302
- Merge moyen
- 23 h
- PR mergées (30 j)
- 8
Description
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.
Guide de contribution
Aucun guide de contribution indexé pour ce dépôt
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Piste de recherche
Commencez par la section liée « type-and-class-objects-vs-protocols » dans docs/spec/protocol.rst, puis lisez la typing discussion liée et le mypy issue pour comprendre la justification associée. L’issue présente des orientations concurrentes plutôt qu’une modification arrêtée ; le travail serait terminé une fois qu’une décision de spécification aura été convenue, puis que la justification et les exemples associés auront été mis à jour.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- python
- Domaine
- documentation
- Type d'issue
- Documentation
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Activité
- À l'abandon
- Clarté
- Plutôt claire
- Accessibilité débutants
- 25/100