Relation constraints between generic callables in a generic dataclass are ignored when constructed in a function call
Ninguém assumiu esta issue ainda.
- Linguagem predominante
- Python
- Estrelas
- 20.6k
- Forks
- 3.3k
- Métricas de merge de PRs
- Métricas de PR pendentes
Descrição
Bug Report
Apologies for the lengthy issue title, but I'm not really sure what to call this. Here is the problematic behavior: Suppose I have two related Generic Callables, Callable[[T1], T2] and Callable[[T2], T3]. These callables are packaged together in a dataclass that is parameterized on T1, T2, and T3. For instance:
T1 = TypeVar("T1")
T2 = TypeVar("T2")
T3 = TypeVar("T3")
@dataclass
class FunctionRelation(Generic[T1, T2, T3]):
func1: Callable[[T1], T2]
func2: Callable[[T2], T3]
I believe it should be an error to construct an instance of the dataclass such that the return-type of the first callable is not the argument type of the second callable. As far as I can tell, this does work correctly in a simple case.
def func_str_int(x: str) -> int:
return int(x)
def func_int_str(x: int) -> str:
return str(x)
def func_str_str(x: str) -> str:
return x
FunctionRelation(func1=func_str_int, func2=func_int_str) # OK
FunctionRelation(func1=func_str_int, func2=func_str_str) # Expected error - Cannot infer T2
However, Mypy incorrectly accepts the bad relation if the dataclass is simply initialized in a function call:
relations: list[FunctionRelation[Any, Any, Any]] = []
def append_to_list(relation: FunctionRelation[T1, T2, T3]) -> None:
relations.append(relation)
append_to_list(FunctionRelation(func1=func_str_int, func2=func_int_str)) # OK
append_to_list(FunctionRelation(func1=func_str_int, func2=func_str_str)) # Incorrectly accepted by Mypy!
relation = FunctionRelation(func1=func_str_int, func2=func_str_str) # Expected error
append_to_list(relation)
FWIW, although Mypy accepts the above example, append_to_list(FunctionRelation(func1=func_str_int, func2=func_str_str)) it is (correctly) identified as an error by Pyright, though Pyright does warn against invalid TypeVar use in the function signature. If the signature is changed from FunctionRelation[T1, T2, T3] to FunctionRelation[Any, Any, Any], then neither Mypy nor Pyright complain, which I believe to be incorrect behavior from both type checkers.
It is very possible my understanding of the expected behavior of Mypy is incorrect here, but there does seem to be an inconsistency in how the types are being treated when a function signature can change the type validity of an object passed to that function, even before the function is called. If this is expected, I would sincerely appreciate help understanding why.
Expected Behavior
If I construct a dataclass D with the following spec
@dataclass
class D(Generic[T1, T2, T3]):
func1: Callable[[T1], T2]
func2: Callable[[T2], T3]
and I have a function F that accepts a D (regardless of how D is parameterized), then I expect that
IF a statement which constructs a D fails type checking,
THEN a statement that constructs a D and passes it to F should ALSO fail type checking.
Actual Behavior
It is possible to construct a D that fails type checking, but to pass type checking by constructing that same D at the same time as passing it to F.
Your Environment
- Mypy version used:
(mypy 0.960+dev.6eac2403f68e33e317c9f17b434d322291e60543 (compiled: no)) - Mypy command-line flags:
None - Mypy configuration options from
mypy.ini(and other config files):strict = true - Python version used:
3.10.4 - Operating system and version:
Arch Linux (5.17.3.arch1-1)
Guia de contribuição
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.
Direção de pesquisa
Comece reproduzindo o exemplo genérico mínimo de dataclass e Callable com strict=true, comparando a construção direta com a construção passada para append_to_list. Rastreie a inferência do tipo genérico para o construtor de dataclass e o argumento da função e, em seguida, adicione cobertura de regressão mostrando que ambas as formas rejeitam a relação incompatível de Callable.
Escrita pelo modelo de indexação a partir do texto da issue.
Avaliação
- Stack de tecnologia
- python
- Domínio
- devtools
- Tipo de issue
- Bug
- Dificuldade
- 4/5
- Tempo estimado
- 3-5 dias
- Status de atividade
- Estagnada
- Clareza
- Razoavelmente clara
- Facilidade para iniciantes
- 35/100