[1.16 regression] Explicit type declaration overridden/merged with Any
Nessuno ha ancora preso questa issue.
- Lingua principale
- Python
- Stelle
- 20.6k
- Fork
- 3.3k
- Metriche di merge delle PR
- Metriche PR in attesa
Descrizione
Bug Report
It appears that explicit type definitions of loop variables can be overridden or merged with values inferred from the iterator. Unfortunately this happens even when the iterator type is Any, somewhat undermining the explicit definition.
To Reproduce
import itertools, typing
class ErrorType:
pass
def report_errors(error_type: ErrorType, id_: object, messages: list[str]) -> None:
pass
errors: list[typing.Any]
source: tuple[ErrorType, object] | None
for source, errors_group in errors:
reveal_type(source) # good: Union[tuple[demo.ErrorType, builtins.object], None]
# bad: Union[tuple[demo.ErrorType, builtins.object], Any]
if source:
reveal_type(source) # good: tuple[demo.ErrorType, builtins.object]
# bad: Union[tuple[demo.ErrorType, builtins.object], Any]
messages: list[str]
report_errors(*source, messages) # bad: Too many arguments for "report_errors"
I've tried reproducing this without the loop, however that seems to make the issue go away.
Removing the messages argument to report_errors also seems to avoid the "too many arguments" error, though that doesn't affect the revealed types so I've left it in to give a clearer pass/fail when running mypy.
Expected Behavior
Under 1.15 and up to 8dd616b7d the above code passes cleanly with the "good" noted revealed types.
Actual Behavior
From b50f3a1a4 onwards the above code fails type checking due to the errant message to the report_errors function, and outputs the "bad" noted revealed types. I'm not familiar enough with mypy to explain why that commit is the cause, however I have narrowed this to that commit using git bisect so I'm fairly confident those changes are related.
Your Environment
Versions as noted above. No command line flags or other config needed.
Python 3.12.3 on Ubuntu 24.04.
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Direzione di ricerca
Inizia eseguendo il riproduttore Python fornito con mypy e confronta il comportamento attorno ai commit 8dd616b7d e b50f3a1a4. Traccia l’inferenza del tipo della variabile di ciclo e la gestione delle dichiarazioni esplicite coinvolte nella regressione. Il lavoro è concluso quando il riproduttore supera nuovamente il test, con i risultati reveal_type segnalati e senza errori errati sul numero di argomenti.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Valutazione
- Stack tecnologico
- python
- Ambito
- compilers
- Tipo di issue
- Bug
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Stato di attività
- Ferma
- Chiarezza
- Abbastanza chiara
- Idoneità per principianti
- 45/100