
Mypy – static type checking for Python 3 - HerrMonnezza
https://github.com/JukkaL/mypy
======
ceronman
Just a few days ago Guido proposed to adopt the Mypy syntax for type
annotations in Python 3.5. There is a big discussion going on on the python-
ideas mailing list about that and the general idea of having optional static
typing in Python:

[https://mail.python.org/pipermail/python-
ideas/2014-August/0...](https://mail.python.org/pipermail/python-
ideas/2014-August/028618.html)

[https://mail.python.org/pipermail/python-
ideas/2014-August/0...](https://mail.python.org/pipermail/python-
ideas/2014-August/028742.html)

Recommended reading for those interested in the topic.

~~~
bsaul
This is probably the best thing i've heard about python in the last 2 years.
Guido's point are all 100% valid.

Python should take example on Typescript. It's light and smart. And that's
enough to cover 99% of the cases.

Just let me specify that function foo's first parameter is an array of
"stuff", and i'll be the happiest man. Leave the complicated cases for future
versions.

------
ak217
I wrote a decorator-driven library to do optional type checking at runtime
with no need for a special interpreter :)

[https://github.com/kislyuk/ensure](https://github.com/kislyuk/ensure)

(Having optional static type checks in the core interpreter would be nice,
though Alex Gaynor's concerns linked in another comment are very valid.)

~~~
untothebreach
I think one of the strengths of Mypy's approach is the fact that it _doesn't_
do type checking at runtime. It may be inconvenient to have a separate step
for type checking, but it also doesn't impart any runtime performance penalty.

------
HerrMonnezza
Former HN discussion at:
[https://news.ycombinator.com/item?id=4561973](https://news.ycombinator.com/item?id=4561973)

Although it seems that MyPy has done a lot of progress since, most notably
adopting Python 3 syntax for type annotations.

------
seivan
Has anyone used this with Django? If it works well I might replace Ruby with
Mypy.

Doing iOS (with Swift) for a while has made me dislike not having static
typing.

------
Goranek
It would be awesome to combine pypy and mypy. Pypy could probable use static
typing to gain some speed.

~~~
thristian
Alex Gaynor, one of the PyPy developers said (on the mailing-list where Guido
proposed this):

 _You 're right. None of this would provide_ any _value for PyPy._

[https://mail.python.org/pipermail/python-
ideas/2014-August/0...](https://mail.python.org/pipermail/python-
ideas/2014-August/028623.html)

~~~
andreasvc
Why is that?

~~~
untothebreach
Because in a dynamically typed language like Python, it is perfectly feasible
that the type declared in the code, and type-checked before the program runs,
is different when the piece of code actually _runs_. Pypy uses runtime types
to make decisions about optimizations, and since those may be different than
the types declared at compile time, it will always have to inspect the runtime
type anyway.

~~~
andreasvc
Then the type annotation is wrong, and it shouldn't be there. Type annotations
only make sense if you know exactly what the types may be at runtime. I still
don't see why correct annotations couldn't help PyPy.

~~~
untothebreach
Type-checking _via_ those annotations, are, like Guido said, basically a
souped-up linter. With a dynamic language like Python, there is _never_ a
guarantee that the types that type-checked during compilation are the types
that will be observed during runtime. Type-checking Python code via function
annotations is nothing like type checking a Haskell program, where you can be
reasonably certain that a program that type-checks will run correctly.

Even if you write a program that you can provably show will never have any
runtime types that differ from compile time types, Pypy can't assume that will
be the case with every program that it tries to run. I don't have any specific
knowledge of the optimizations that Pypy runs, but if one of the core
contributors of Pypy says it can't be done, I'm inclined to believe him.

~~~
andreasvc
It is trivial to write a function that always returns a specific type, e.g.,
def f(): return 1

Therefore your claim that there is "_never_ a guarantee" is simply false. I
was asking: what if you DO want PyPy to assume that your types are correct,
why couldn't that help?

~~~
untothebreach
Monkeypatching means that `def f(): return 1` could be turned into `def f():
return "i am now a string!"` at runtime, so I stand by my original statement.

EDIT: Here is a trivial example of a program that type checks at compile time
but doesn't present the same types at runtime. Obviously you would never do
this in production code, but the same effect could be accomplished simply by
doing an `import somemodule`.

[http://codepad.org/OarBYXfZ](http://codepad.org/OarBYXfZ)

~~~
andreasvc
Your replacing what 'f' is bound to; this would include replacing any type
annotations, and triggering any system that relies on type annotations to
drop/reset its optimizations for 'f'. You're not actually rewriting the
original function to return something different; this would probably also be
possible, but would be considered as even more of a dirty trick.

It is unfortunate that such dynamicity is the default in Python, when in
reality it is rarely needed. So it would be advantageous to be able to tell
the optimization system: this function is not going to change dynamically (on
an opt-in basis).

