[Python-Dev] Type hints -- a mediocre programmer's reaction

[Robert Collins]

On 21 April 2015 at 10:02, Ian Cordasco <graffatcolmingov at gmail.com> wrote:
>
>

>
> So I've generally stayed out of this but I feel there is some context that
> people are missing in general.
>
> First, allow me to provide some context: I maintain a /lot/ of Python
> code[1] and nearly all of it is designed to be compatible with Pythons 2.6,
> 2.7, 3.2, 3.3, 3.4 (and eventually 3.5) and sometimes 2.5 (depending on the
> project). If I want to improve a developer's experience with some of that
> code using Type Hints I will essentially have no way to do that unless I
> write the code with the annotations and ship versions with annotations
> stripped and other versions with annotations? That's a lot more overhead. If
> I could provide the annotations in stubs that means that only the people who
> care about using them will have to use them.

2.5? I'm so sorry :).

Being in approximately the same boat, I definitely want to be able to
improve the developer experience.

That said, with one key exception (str/bytes/unicode) Python code
generally has the same type on all versions. Sure it might be imported
from somewhere else, and you're restricted to the common subset of
APIs, but the types in use don't vary per-python.

So - as long as your *developers* can run mypy on 3.2+, they can
benefit from type checking. mypy itself requires 3.2+ to run, but
programs with type annotations should be able to run on all those
python versions you mention.

Now, what is the minimum barrier for entry?

Nothing :) - at the moment every file can be analysed, and mypy ships
with a bunch of stubs that describe the stdlib. So - you'll get some
benefit immediately, where bad use of stdlib routines is happening.

Constraining the types of functions gets you better errors (because
you are expressing intent rather than what-might-happen which the
inference has to work from otherwise. In particular, constraining the
type of *inputs* can let bad callers be detected, rather than the
engine assuming they are valid-until-a-contradiction-occurs. You can
do that with stub files: put them in repo A, and add them to the
MYPYPATH when working on repo B which calls the code in repo A. You
can also add those stubs to repo B, but I wouldn't do that because
then they will skew vs repo A.

A further step up would be to annotate A in its code, rather than
using stubs. That way, developers of repo A will be warned about bad
uses of other repo A code.

But - if you have stubs *or* annotations in-line in repo A, *everyone*
changing repo A needs to care. Because if the code mismatches the
stub, the folk that do care will now be unable to use repo A correctly
- their type checker will complain about valid uses, and fail to
complain about more invalid uses.

I'm particularly interested in mypy for OpenStack because for some
repos > 10% of reported bugs are type mismatch errors which mypy may
well have avoided.

> Is it more overhead to manage twice the number of files? Yes. Do I feel it
> would be worth it to not overly complicate how these packages are released?
> Yes.

> Further, there are far more reasons to make stubs the baseline (in my
> opinion) the biggest reason of all is that people want to provide stubs for
> popular yet unmaintained libraries as third party packages. Should everyone
> using PIL be using Pillow? Of course. Does that mean they'll migrate or be
> allowed to migrate? No. Should they be able to benefit from this? Yes the
> should. The only way for PIL users to be able to do that is if stub files
> can be packaged separately for PIL and distributed by someone else.

stubs can certainly be packaged and distributed separately. That
doesn't make the case that we should use stubs for projects that are
opting in.

> I think while the authors are currently seeing stubs as a necessary *evil*
> they're missing points where they're a better backwards compatible solution
> for people who want to give users with capable IDEs the ability to use stub
> (or hint) files.

-Rob


-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud