Mypy 0.3 Released – optional static type checker for Python | Hacker News Reader

Mypy 0.3 Released – optional static type checker for Python

mypy-lang.blogspot.com

77 pointsingve19 comments

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!

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?

> People that use python 2 generally maintain existing code base.

Yeah, probably maintaining large, legacy codebases, which are underdocumented and undertested but over-architected to compensate... And such people would immediately and directly benefit from an optional static type-checker. So maybe it's for them?

python 2 has a lot more implicitness when it comes to types (everything is comparable with everything else, unicodestrings/bytestrings autoconvert, etc.

> People that use python 2 generally maintain existing code base.

maintain being a key word there, finding bugs before they become a problem is always a good thing.

- - -

Also python 2 is maintained beyond security patches, but only by third parties: the core developers won't be adding new features, but third parties are welcome to spend time and effort to backport python 3 features to python 2 (as long as it isn't an incompatible change for py2)

At least that is what my understanding of the situation is

Authors of libraries, frameworks, and tools that must support Python 2.

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.

> 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.

there are tons of businesses that write only python 2 code (like, every finance shop I've ever worked or consulted at)

I understand that, but if they are not willing to port their code to python 3, what would make them go through their old code and start annotating types in it?

Python 2 is supposed to be dead but it's very much alive. What should have been a simple version upgrade became a fork.

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")

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"

"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."

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.

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 :)

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.

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?

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.

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

Reply on news.ycombinator.com