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
mypy prints out types in inconsistent formats depending context #1582
Mypy has several different ways types can be displayed: the internal representation, format_simple, etc. It's confusing that the same type can be printed differently in different places. Also,. none of these formats look quite like the PEP 484 syntax.
It'd be really nice to make one canonical way that types are printed, which should look exactly like the PEP 484 syntax (but with slight additional information about type variables when appropriate). I don't think this will even be too hard to write -- the main annoyance will be updating all the tests.
Yeah, printing types is currently messy and it would be nice to clean it up. PEP 484 doesn't allow printing out all the information about types, such as *args in callable types, so we may still decide to continue having some non-standard forms.
It may still be nice to have at least two different modes:
Show a type.
Show the difference between two types. We'd fall back to showing both types, but in some cases it can be useful to highlight how the two (complex) types are different/incompatible. A simple implementation would just align the types on top of each other so that the difference is easy to spot.
Yeah, showing stuff like *args information seems good. I think we should aim for a sort of PEP 484++ syntax, which is a superset of PEP 484 syntax with additional information where appropriate (and we should try to think a carefully what that additional info looks like).
I like the idea of alignment for the type difference mode. I don't think there should be any other difference in how the types are printed, though. In particular, I think we should always print full types and never abbreviate.
I just stumbled upon this problem as well... I wondered why the error happened only when using classes that I defined (like RateType and not by using primitives (int, str))... until I realized it might've been the length of the string representation of the type itself, and I managed to reduce the test case I was using to
from typing import Tuple
class AAAAAAA: pass
class BBBBBBBBBBBBB: pass
def f(v: Tuple[AAAAAAA, AAAAAAA, BBBBBBBBBBBBB]):
pass
f((BBBBBBBBBBBBB(), AAAAAAA(), AAAAAAA()))
which yields the puzzling error:
Argument 1 to "f" has incompatible type tuple(length 3); expected tuple(length 3)
Activity
JukkaL commentedon May 26, 2016
Yeah, printing types is currently messy and it would be nice to clean it up. PEP 484 doesn't allow printing out all the information about types, such as
*argsin callable types, so we may still decide to continue having some non-standard forms.It may still be nice to have at least two different modes:
ddfisher commentedon May 26, 2016
Yeah, showing stuff like
*argsinformation seems good. I think we should aim for a sort of PEP 484++ syntax, which is a superset of PEP 484 syntax with additional information where appropriate (and we should try to think a carefully what that additional info looks like).I like the idea of alignment for the type difference mode. I don't think there should be any other difference in how the types are printed, though. In particular, I think we should always print full types and never abbreviate.
berdario commentedon Jun 15, 2016
I just stumbled upon this problem as well... I wondered why the error happened only when using classes that I defined (like
RateTypeand not by using primitives (int,str))... until I realized it might've been the length of the string representation of the type itself, and I managed to reduce the test case I was using towhich yields the puzzling error:
ilevkivskyi commentedon May 18, 2018
Mypy now shows full types when necessary so this may be closed.