New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

type hints and mypy #831

Open
obestwalter opened this Issue May 26, 2018 · 6 comments

Comments

Projects
None yet
3 participants
@obestwalter
Member

obestwalter commented May 26, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@RonnyPfannschmidt

RonnyPfannschmidt May 26, 2018

Contributor

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

Contributor

RonnyPfannschmidt commented May 26, 2018

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

@obestwalter

This comment has been minimized.

Show comment
Hide comment
@obestwalter

obestwalter May 26, 2018

Member

ah .. o.k. will do :)

Member

obestwalter commented May 26, 2018

ah .. o.k. will do :)

@obestwalter

This comment has been minimized.

Show comment
Hide comment
@obestwalter

obestwalter May 26, 2018

Member

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?

Member

obestwalter commented May 26, 2018

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

This comment has been minimized.

Show comment
Hide comment
@gaborbernat

gaborbernat May 26, 2018

Member

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.

Member

gaborbernat commented May 26, 2018

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

This comment has been minimized.

Show comment
Hide comment
@obestwalter

obestwalter May 26, 2018

Member

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.

Member

obestwalter commented May 26, 2018

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

This comment has been minimized.

Show comment
Hide comment
@obestwalter

obestwalter May 26, 2018

Member

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.

Member

obestwalter commented May 26, 2018

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.

@gaborbernat gaborbernat added this to the 3.2 milestone Jul 3, 2018

@gaborbernat gaborbernat self-assigned this Jul 3, 2018

@gaborbernat gaborbernat modified the milestones: 3.2, 3.3 Jul 9, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment