1. 5
  1.  

  2. 3

    I did not write this blog post, but I work on pytype, in case anyone has questions about it.

    1. 2

      Thank you for your work. I guess my main question would be, how do pytype and mypy compare?

      1. 1

        the biggest difference is that pytype does whole-file type inference for unannotated code, so you can just run pytype over your project without having to do anything. (as a nice consequence of this we can also generate type stubs for you, and optionally even merge them into your source code as annotations).

        another architectural difference is that mypy (i believe) reads an entire project into memory at once; pytype processes one file at a time and analyses the dependency graph to sequence operations. apart from being less memory-intensive, this also lets us run in parallel (we generate a ninja file that mirrors the depgraph and then use ninja to run in parallel if we can). the dependency analyser has been split off into its own project, importlab, which is independent of pytype.

        also, pytype can run under python2 or python3 (mypy can analyse python2 code, but it needs a python3 interpreter to run mypy itself).

        pytype also ships with a patch for python 2.7 that backports the type annotation syntax from python3, though that is not needed to run (we support the regular comment-based type annotations as well).

        1. 2

          Awesome, thanks for the detailed response.

          Are the type systems of mypy and pytype roughly equivalent? Can pytype handle recursive types? (Mypy has very little support for recirsive types currently.)

          I’d also love to see some sort of dependent typing for Python. Mypy has some very simple dependent types (used, for example, for checking the values of literal strings in the mode argument of open), but a richer dependent type mechanism would make it possible to express useful things like “unsigned integer” or “nonempty set” types.

          Either way, thanks again. I’ll be sure to check out pytype.

          1. 2

            there is a typing standard, PEP484, that both mypy and pytype follow (as do other projects like facebook’s pyre), so we do all have the same notion of types. there are a few minor differences, e.g. pytype supports container type mutation, so that adding a string to a List[int] would change it to a List[int|str], whereas mypy would reject the addition with a type error.

            pytype does support recursive types; not sure what mypy’s support is like so i can’t compare them, but for instance this works:

            $ cat > t.py
            class Tree:
                def __init__(self, left: 'Tree', right: 'Tree'):
                    self.left = left
                    self.right = right
            
            $ pytype t.py -V 3.6 -o -
            class Tree:
                left: Tree
                right: Tree
                def __init__(self, left: Tree, right: Tree) -> None: ...
            

            dependent types are probably a good way down the road, if at all, except for some special instances like you mention. my personal feeling is that it will end up being a collection of special instances that provide a high return on investment, rather than any general depedndent typing mechanism.

            i am currently excited about the shape annotations for numeric arrays proposal (scroll down), which would be an excellent addition to the python type system and allow all sorts of numeric libraries to be better supported, as well as the associated dataframes typing.