Skip to content

mypy prints out types in inconsistent formats depending context #1582

Closed

Description

@ddfisher

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.

Activity

  1. JukkaL commented on May 26, 2016

    @JukkaL
    Collaborator

    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:

    1. Show a type.
    2. 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.
  2. ddfisher commented on May 26, 2016

    @ddfisher
    CollaboratorAuthor

    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.

  3. berdario commented on Jun 15, 2016

    @berdario

    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)
    
  4. ilevkivskyi commented on May 18, 2018

    @ilevkivskyi
    Member

    Mypy now shows full types when necessary so this may be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions