Will you accept PRs with pep484 type hints?

[mkurnikov]

There is a recent blog post in Zulip's blog:
http://blog.zulip.org/2016/10/13/static-types-in-python-oh-mypy/

It looks like Zulip gained a lot from type hints.

Pip could use the same # type: comments as Zulip, which described here:
https://www.python.org/dev/peps/pep-0484/#suggested-syntax-for-python-2-7-and-straddling-code

[pfmoore]

IMO, not if it's just isolated hints or a one-off contribution. But if someone wanted to work on a project to add hinting (and the associated testing, etc., infrastructure) to pip, then maybe.

Personally, I'd like to experiment with type hints, but I have no experience with them, or time to do so. My biggest concern is that they should remain completely optional, at least initially, so that we don't impose a "big bang" change on contributors. That doesn't just mean "we don't need to annotate every function", it also has the following implications:

1. Do we need infrastructure to check those hints (e.g., a travis job like the pep8 checks)? What impact would that have on CI run that's already pretty long? We can't expect developers to run type checkers locally.
2. Would we make the type checks optional? Given that many people are unfamiliar with typing, I wouldn't want to enforce them yet.
3. How do we keep the checks correct if the validation is optional? Not just if someone modifies an annotated function, but what if they use an annotated function in the wrong way? Worse, what if their use isn't actually wrong, it's the type hint that's too strict? We can't expect someone submitting a PR to suddenly need to correct type data - it's already frustrating enough to have to go through the cycle of fixing pep8 violations on a PR...

Maybe a WIP-style PR that added checking infrastructure and some basic checks, so that people could assess the impact, would be worthwhile. It's not clear (to me, at least) if it would be accepted, but it would at least allow us to see the impact.

My biggest concern would be that none of the pip developers are likely to have time to add or maintain type annotations, and it's not clear to me whether we'd get annotated PRs, or we'd have to deal with how we handle accepting PRs without annotations. If we don't have the time to manage such a project, it would need a contributor who can commit the time to follow such a project through. And that may well take months - big changes are notoriously slow to land in pip (core dev time constraints, again...)

My instinct is that type hints would be a definite benefit for pip's codebase. But it's not a high priority compared to a number of other things we need to get done.

[pradyunsg]

Would we make the type checks optional? Given that many people are unfamiliar with typing, I wouldn't want to enforce them yet.
How do we keep the checks correct if the validation is optional?

IIUC, mypy checks only the functions that are annotated or places where it can infer what type an object has. Everything else get a Any type assigned with allows everything. So, if mypy knows the types of a function and the type of a variable, it will run the check. Otherwise, it is a green flag.

Not just if someone modifies an annotated function, but what if they use an annotated function in the wrong way? Worse, what if their use isn't actually wrong, it's the type hint that's too strict? We can't expect someone submitting a PR to suddenly need to correct type data - it's already frustrating enough to have to go through the cycle of fixing pep8 violations on a PR...

I have experimented with PEP484 (albeit not much), I would say it's not likely that something like this happens. In the one case that something like this did happen with me, it was indeed poor design decision.

Do we need infrastructure to check those hints (e.g., a travis job like the pep8 checks)? What impact would that have on CI run that's already pretty long? We can't expect developers to run type checkers locally.

I think the CI job is necessary. How long it'll take, no idea.

mypy depends on typing module from PyPI for < 3.5, which might have to be bootstrapped with pip.

---

I'm starting to tackle this now.

[dstufft]

I'm going to close this issue as I don't think having it open adds value. On the topic of type hints, I am neutral on them but if someone wrote a PR that added them I would at least review it.