Skip to content

type hints and mypy #831

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

Closed
obestwalter opened this issue May 26, 2018 · 10 comments
Closed

type hints and mypy #831

obestwalter opened this issue May 26, 2018 · 10 comments
Assignees
Labels
help:wanted Issues that have been acknowledged, a solution determined and a PR might likely be accepted. level:hard rought estimate that this might be quite hard to implement type:internal should have no impact on the user (refactoring, infrastructure, tools, etc.)
Milestone

Comments

@obestwalter
Copy link
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

@obestwalter obestwalter added type:internal should have no impact on the user (refactoring, infrastructure, tools, etc.) help:wanted Issues that have been acknowledged, a solution determined and a PR might likely be accepted. labels May 26, 2018
@RonnyPfannschmidt
Copy link

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

@obestwalter
Copy link
Member Author

ah .. o.k. will do :)

@obestwalter
Copy link
Member Author

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
Copy link
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
Copy link
Member Author

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
Copy link
Member Author

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 added the level:hard rought estimate that this might be quite hard to implement label Jul 3, 2018
@gaborbernat gaborbernat self-assigned this Jul 3, 2018
@gaborbernat gaborbernat modified the milestones: 3.2, 3.3 Jul 9, 2018
@obestwalter
Copy link
Member Author

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.

@gaborbernat
Copy link
Member

I personally would prefer it beforehand. it's blocked for now on merging stubs and sources at mypy level. At tox is a library for our plugin developers.

@gaborbernat
Copy link
Member

We'll do this after #1130.

@gaborbernat gaborbernat removed this from the 3.3 milestone Jan 9, 2019
@jugmac00
Copy link
Member

jugmac00 commented Mar 3, 2021

I'd say this issue could be closed - analogous to #1130 - as the tox rewrite branch uses typing.

@gaborbernat gaborbernat added this to the 4.0 milestone Mar 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help:wanted Issues that have been acknowledged, a solution determined and a PR might likely be accepted. level:hard rought estimate that this might be quite hard to implement type:internal should have no impact on the user (refactoring, infrastructure, tools, etc.)
Projects
None yet
Development

No branches or pull requests

4 participants