type hints and mypy

[obestwalter]

@gaborbernat and me recently discussed about introducing type hints. I stumbled over pyannotate to help adding them, if we decide to do so and started to add some boilerplate in a branch. I won't have the time to pursue that, but if anyone wants to experiment with it - this would be the starting point: https://github.com/tox-dev/tox/tree/pyannotate-type-hints

[RonnyPfannschmidt]

@obestwalter for ease of taking a look please consider opening a [wip] pr

[obestwalter]

ah .. o.k. will do :)

[obestwalter]

Hi @gaborbernat, you mentioned doing something similar in a different branch with a different tool. I just had a look and have a few questions, because I am not quite sure if we are talking about the same thing. I just started to look into the whole topic, so I might have some gaps and misconceptions ...

From glimpsing at the stubs, they seem to be meant to exist outside of the code base like PyCharm did it with skeletons. The "new" way of doing that is to have a type shed then for libraries. They would live in something like https://github.com/python/typeshed for the stdlib. IIUC they would not be part of the source code. The intention for these stubs is mainly to provide type hints for IDEs to improve code completion behaviour.

The approach I was having in mind would contain the type information right in the source code, e.g.

def greet_world(): # type: () -> None
    print "Hello, world!"

[...]

def call(self, *args, **kwargs):
         # type: (*str, **str) -> str
         request = make_request(*args, **kwargs)
         return self.do_api_query(request)

(from http://mypy.readthedocs.io/en/latest/cheat_sheet.html)

Or am I missing something and those stubs are also used by a tool (or mypy directly) to automatically add the type hints to the code base?

[gaborbernat]

Hello @obestwalter, they are multiple ways you can add type hints; stubs, annotations, comments; etc. All of them have some negative and some positive about it. Stubs at the moment are mostly used in typeshed, and to type annotate libraries that don't provide type annotations directly. That being said once python/mypy#5028 is solved, it can be used to type annotate source files directly (e.g. libraries itself). The advantage of this is that you don't need to add any runtime overhead by adding type data (e.g. imports, aliases, protocol definitions, etc - yeah things get complicated once you go beyond the simple hello world example) into your code (which often makes the code seem longer and more obfuscated ironically). I have written a longish blog article about type hints in Python under https://www.bernat.tech/the-state-of-type-hints-in-python/, you might want to go over it. It's in its first draft phase, so needs some style fixes, but content-wise should be there.

[obestwalter]

Thanks for the clarification. I just checked python/mypy#5028 and saw that you are driving that 👍 - I will have a look at the blog artice also.

[obestwalter]

I just skimmed over your blog post. This looks like it's shaping up to be a great overview over the whole topic (it's also good to look at some penguins now and then :)). I will read this thoroughly next week, when I have a bit more time and might bother you with some more qestions, corrections and suggestions then.

[obestwalter]

Here's a thought: once we dropped Python2.7 we can start applying gradual typing manually where it makes sense (e.g. where it helps humans and IDEs to figure out the more dynamic corners in tox).

I don't really think that anything else is needed. tox is not a library where others need type hints in type sheds or wherever so we should keep it simple here.

Mechanically adding type hints to the whole code base also feels wrong to me.