[Python-Dev] Type hints -- a mediocre programmer's reaction
Guido van Rossum
guido at python.org
Tue Apr 21 05:37:28 CEST 2015
On Mon, Apr 20, 2015 at 4:41 PM, Jack Diederich <jackdied at gmail.com> wrote:
> Twelve years ago a wise man said to me "I suggest that you also propose a
> new name for the resulting language"
The barrage of FUD makes me feel like the woman who asked her doctor for a
second opinion and was told "you're ugly too."
> I talked with many of you at PyCon about the costs of PEP 484. There are
> plenty of people who have done a fine job promoting the benefits.
So excuse me if I also defend the PEP against your attack.
> * It is not optional. Please stop saying that. The people promoting it
> would prefer that everyone use it. If it is approved it will be optional in
> the way that PEP8 is optional. If I'm reading your annotated code it is
> certainly /not/ optional that I understand the annotations.
The PEP 8 analogy is actually great -- that PEP's style advice *is*
optional and plenty of people ignore it happily. The benefits come out when
you're sharing code but violations are no big deal.
And as to requiring what the annotations mean: the CPython interpreter
itself doesn't even use them when executing your code, so you can certainly
pretend that the annotations aren't there and read the body of the function
or the docstring instead.
> * Uploading stubs for other people's code is a terrible idea. Who do I
> contact when I update the interface to my library? The random Joe who
> "helped" by uploading annotations three months ago and then quit the
> internet? I don't even want to think about people maliciously adding stubs
> to PyPI.
We're certainly not planning to let arbitrary people upload stubs for
arbitrary code to PyPI that will automatically be used by the type
checkers. (We can't stop people from publishing their stubs, just as you
can't stop people from writing blog posts or stackoverflow answers with
examples for your library.)
The actual plan is to have a common repository of stubs (a prototype exists
at https://github.com/JukkaL/typeshed) but we also plan some kind of
submission review. I've proposed that when submitting stubs for a package
you don't own, the typeshed owners ask the package owner what their
position is, and we expect the answers to fall on the following spectrum:
- I don't want stubs uploaded for my package
- I'll write the stubs myself
- I want to review all stubs that are uploaded for my package before they
- Please go ahead and add stubs for my package and let me know when they're
- Go ahead, I trust you
This seems a reasonable due diligence policy that avoids the scenarios
you're worried about. (Of course if you refuse stubs a black market for
stubs might spring into existence. That sounds kind of exciting... :-)
> * The cognitive load is very high. The average function signature will
> double in length. This is not a small cost and telling me it is "optional"
> to pretend that every other word on the line doesn't exist is a farce.
Have you never found yourself trying to read someone else's code and being
stopped in your tracks because you couldn't find out what kind of argument
was expected somewhere? I'm personally quite tired of seeing that an
argument is a "file" and not knowing whether it's meant to be an IO stream
or a filename (and was that bytes or unicode? :-). Or seeing something
documented as "creation time" without knowing whether that's a datetime or
a a POSIX timestamp (or maybe milliseconds or a string encoding a date).
And yes, you can put the info in docstrings or comments (though it won't be
less verbose, and it will be more likely wrong). One way to see type hints
is as a way to save on docstrings and comments by using a standard notation
that ties type info to the argument without the need to repeat the argument
Yes, you need to use your brain. But don't tell my that all the Python code
you read or write is self-explanatory, because it isn't.
> * Every company's style guide is about to get much longer. That in itself
> is an indicator that this is a MAJOR language change and not just some
> "optional" add-on.
Actually, standardization *reduces* the length of a company style guide,
like PEP 8 did before. Would you rather have instructions for the specific
linter your company uses, instead of the single phrase "use type hints (PEP
> * People will screw it up. The same people who can't be trusted to program
> without type annotations are also going to be *writing* those type
I don't follow this argument. So what? People will screw up anything you
give them. introspection, metaclasses, import hooks, reduce(), you name it.
> * Teaching python is about to get much less attractive. It will not be
> optional for teachers to say "just pretend all this stuff over here doesn't
This argument is particularly weak. Teachers are actually *very* effective
teaching only the parts of Python they need -- some start with just
functions and variables. Others with just classes and methods. Few ever
even teach operator overloading.
> * "No new syntax" is a lie. Or rather a red herring. There are lots of new
> things it will be required to know and just because the compiler doesn't
> have to change doesn't mean the language isn't undergoing a major change.
The language undergoes major changes all the time. There was a time before
context managers. You've survived print() becoming a function. We're
getting a matrix multiply operator. The sky isn't falling.
> If this wasn't in a PEP and it wasn't going to ship in the stdlib very few
> people would use it. If you told everyone they had to install a different
> python implementation they wouldn't. This is much worse than that - it is
> Python4 hidden away inside a PEP.
But the nice thing is that this time you really *can* mix Python 3 and
Python 4 together in one app. :-P
> There are many fine languages that have sophisticated type systems. And
> many bondage & discipline languages that make you type things three times
> to make really really sure you meant to type that. If you find those other
> languages appealing I invite you to go use them instead.
So finally it's payback time? Well played sir. :-)
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev