You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Unbound parameters of type aliases silently default to Any #3386
This may just be my misunderstanding, but it seems potentially undesirable, so I am reporting it as a bug. As of mypy 0.511, this typechecks just fine:
from typing import TypeVar, Tuple
V = TypeVar('V', bound=int)
E = Tuple[V, V]
def outgoing(edge: E) -> V: # Note unparameterized E
reveal_type(edge) # Revealed type is 'Tuple[Any, Any]'
return edge[1]
print(outgoing((1, 'a')))
It looks like declaring a variable of type E ought to be the same as declaring it of type Tuple[V, V], but in fact it becomes Tuple[Any, Any]. The issue is that the alias itself requires a type parameter (E[V]). This is a mistake that is both easy to make and silently removes type safety. Unfortunately, the PEP and docs are not very clear about aliases needing parameters.
I'm not sure if there is a use case for missing alias parameters defaulting to Any, but it seems like type safety would be greatly improved it produced a typechecking error instead. It would really be convenient if mypy could try to bind missing type alias parameters to bound parameters of the same name, which would improve both usability and type safety. Thanks!
Could you tone down your language? I understand this bit you and maybe it's not explained well enough but you sound really hostile which doesn't help anything.
Activity
gvanrossum commentedon May 20, 2017
Could you tone down your language? I understand this bit you and maybe it's not explained well enough but you sound really hostile which doesn't help anything.
jkleint commentedon May 21, 2017
You're right, I was a bit harsh. My apologies. I've edited the text to be more neutral. Thank you.
ilinum commentedon May 22, 2017
I believe @pkch tried to address this issue in #3141. Perhaps, we can finish up that PR and merge it.
I didn't actually test it but it seems like the issue should be fixed by the PR.
gvanrossum commentedon May 22, 2017
@ilinum Would you want to review this PR? I'm not sure otherwise how to proceed (I don't know the area of the code it touches very well).
ilinum commentedon May 23, 2017
@gvanrossum Yes, I will! :)
ilevkivskyi commentedon Oct 5, 2017
We now have
--disallow-any=generics, so this can be closed now.