Reason given for disallowing non-concrete subtype assignment is unsound
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 5/5
- Tempo estimado
- Mais de uma semana
- Facilidade para iniciantes
- 25/100
- Tipo de issue
- Documentação
- Clareza
- Razoavelmente clara
- Status de atividade
- Estagnada
- Stack de tecnologia
- python
- Domínio
- documentation
Direção de pesquisa
Comece pela seção vinculada «type-and-class-objects-vs-protocols» em docs/spec/protocol.rst e, em seguida, leia a typing discussion vinculada e o mypy issue para entender a justificativa ao redor. O issue apresenta direções concorrentes em vez de uma mudança definida; o trabalho estaria concluído após uma decisão acordada sobre a especificação, seguida de atualizações na justificativa e nos exemplos associados.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
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.
- Linguagem predominante
- Python
- Estrelas
- 1.8k
- Forks
- 302
- Merge médio
- 23h
- PRs com merge (30d)
- 8
Guia de contribuição
Nenhum guia de contribuição indexado para este repositório
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de python/typing
-
topic: typing spec
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
-
topic: typing spec
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
-
topic: documentation
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 76/100
-
topic: documentation
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 65/100
-
topic: conformance tests topic: typing spec
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 72/100
Todas as issues de python/typing
Issues semelhantes
-
area: harness bug status: needs-triage
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
Human-Agent-Society/reef#625 ·
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 70/100
-
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 80/100
learningequality/kolibri#15351 · 2 comentários ·
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
-
Name consistency Aberta
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
eellak/triplestore#65 · 1 comentário ·