
Mypy 0.3 Released – optional static type checker for Python - ingve
http://mypy-lang.blogspot.com/2016/02/mypy-03-released.html
======
wittekm
We've been using the Python 2 support at work for the past ~month and it's a
gamechanger for me personally. I like that it's easy to incrementally add
types, and silo it to one piece of the codebase at a time.

Thanks Jukka!

------
takeda
I don't understand who would want the python 2 support, the language does not
natively support types, is no longer maintained (except for security patches).
People that use python 2 generally maintain existing code base.

Wouldn't be better to concentrate on 3.x only and full async support?

~~~
oconnor663
My guess for the most immediate reason is that Dropbox uses a lot of Python 2,
and it sounds like they're paying for the vast majority of mypy's development.

Apart from the sweet sweet cash though, missing Python 2 support makes it
harder for people to take you as a dependency. I think it's similar to why a
lot of Python projects put in the effort to add Windows support, even if only
a tiny fraction of their users actually run Windows. If your project doesn't
support Windows/Python 2, and my project does, I can't take you as a
dependency. If my project _might ever in the future_ support Windows/Python 2,
I can't take you as a dependency. That's a huge drag on adoption.

I sincerely hope that in five years, supporting `async`/`await` will be more
important for adoption than supporting Python 2.

~~~
munificent
> I think it's similar to why a lot of Python projects put in the effort to
> add Windows support, even if only a tiny fraction of their users actually
> run Windows.

My experience is that most developers who personally use _nix OSes_ vastly*
underestimate the number of Windows developers out there.

------
ryanprichard
I tried it on this bit of code, but it didn't detect a type mismatch. Is it
supposed to?

    
    
      def foo(n: int):
          pass
      def bar():
          foo("123")
    

It _does_ detect this mismatch:

    
    
      def foo(n: int):
          pass
      foo("123")

~~~
ddfisher
This _is_ intended behavior, actually! By default, mypy doesn't type check the
interior of functions that don't have any type annotations. This lets you
slowly introduce types to a large codebase without having to convert
everything at once (or even file by file). Adding a type annotation to "bar"
will cause mypy to check it:

    
    
      def foo(n: int):
          pass
      def bar() -> None:
          foo("123")
    
      >> main: note: In function "bar":
      >> main:4: error: Argument 1 to "foo" has incompatible type "str"; expected "int"

------
atrudeau
"Great! Been waiting for this forever. Now off to type all my code!" ... 2
years later ... "So yeah, still haven't gotten around to it, but I will." ...
50 years later ... "Turns out I'm more of a run-it-and-see guy."

~~~
mpweiher
Well, that was my experience when Objective-C got static types (yes, I'm old).
I thought it would be awesome, but then I found that after you got the code to
run, there really wasn't much of a need for the static types.

Later I did find a documentation benefit for certain situations.

~~~
oconnor663
This is where I'm hoping for a "mypy-strict" mode. I don't care enough about
future-me to add types to every single function I write. But I do care enough
about future-me to add a single line to a config file, if that means a tool
can force me to add types to every single function I write :)

------
StavrosK
I wanted to use MyPy with a Django project, but it produced so many errors as
to be useless. Has anyone had any success with it? It sounds very helpful
overall, if one can make it work.

------
ralmidani
Python/Django user here. Could someone help me understand the benefits of
optional typing aside from less need for unit tests? Isn't one of the main
selling points of static typing the speed benefit of knowing beforehand how
much memory to allocate for a variable?

------
stcredzero
For programs like servers, it might be nice to be able to export runtime type
information out of a tracing JIT VM, like PyPy. There have been studies that
found, after an initialization period, that types in server applications tend
to "settle down" in languages like Python. So large parts of the codebase of
such applications could be usefully typed by information generated by a
tracing JIT VM.

------
michaelmior
One big piece of news that's easily missed is that Guido (Python PDFL) joined
the project.

