Specify methods that are allowed for inference of partially initialized generics
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 5/5
- Tempo estimado
- Mais de uma semana
- Facilidade para iniciantes
- 25/100
Direção de pesquisa
Nenhum arquivo-fonte ou teste é mencionado. Comece revisando os exemplos da proposta para contêineres vazios e as APIs de Estimator do scikit-learn; em seguida, leia a issue vinculada do MyPy e a discussão sobre TypeAssert. O trabalho estará concluído quando houver acordo sobre se métodos além de init podem inferir parâmetros genéricos e quando a sintaxe e o comportamento aceitos estiverem definidos.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
The inference of generic types for classes in most type-checkers assume that all the generic types can be inferred from the parameters to __init__. This is not always the case. For example, it is a common pattern to create an empty container class and add elements to it later, e.g.:
a = []
a.append("hello world")
Currently for builtin classes, such as list or dict, this idiom is understood by MyPy, but not by Pyright. Moreover, even MyPy is incapable of applying this type inference to custom types (see https://github.com/python/mypy/issues/13134). As mentioned in that issue, the problem is not only with empty containers, but also with some widely used APIs, such as the Estimator API from scikit-learn and related projects, in which the type of the data used is only known when the fit method is called.
My proposal would be to add functionality to the type system to define which methods can be used to infer generic types, apart from __init__. This could be made for example with a decorator (e.g. allow_generic_inference), so that one can define a method such as:
@allow_generic_inference
def append(value: T):
...
In this case the value of the class generic parameter T could be inferred from append if it was undefined before.
I think this proposal may also be similar to the previously suggested TypeAssert mentioned by @erictraut in https://github.com/python/typing/discussions/1013#discussioncomment-1966238. However I am not completely sure that TypeAssert could do what I explained here. I am also not sure that the proposed TypeAssert syntax is better than a decorator.
I hope you too consider this proposal useful, and I look forward to your feedback.
- 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
-
bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
stephrobert/dsoxlab#238 ·
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
sublimehq/package_control#1780 ·
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 65/100
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 70/100
nwg-piotr/nwg-displays#145 ·