[Python-ideas] PEP 484 (Type Hints) -- first draft round

Dennis Brakhane brakhane at googlemail.com
Fri Jan 16 21:34:59 CET 2015

Am 16.01.2015 um 20:45 schrieb Guido van Rossum:
> That's discussed in this section:
> https://www.python.org/dev/peps/pep-0484/#compatibility-with-other-uses-of-function-annotations
> .
I still feel that saying "if you use function annotations, that function
cannot be statically checked" is bad.

If type hints are successful, many projects will adopt them, especially
big projects and/or projects in corporations. Probably many will require
that all code must pass the type checker, and (at least) public
functions be type annotated.

Let's suppose that indeed happens. If I now were writing a new open
source Python library, I would want that my library could be used in big
projects, and therefore would have an incentive to type annotate my
library. If I don't, a big project might choose another lib instead that

So in that future, a library that wants to be successful basically can't
use type annotations, even if they would have been an elegant solution
to a particular problem. That feels somewhat wrong to me.

A possible work around using skeletons seems ugly, you would have to
edit two different files and keep them in sync.

I feel there should be another way to make type annotations and
"creative" annotations coexist.

> The dict notation (which was proposed in an earlier thread on
> python-ideas) looks too messy to seriously support.
How about using a tuple? I'll admit that I've proposed it before, but
got no reaction.

If an annotation is a tuple, the type checker would check each element
for known values, and every other thing that uses __annotations__ could
do the same. Stefan's example could look something like

  def func(x: (str, wobble(False), ctype('std::string[utf8]'))) -> (str,

It's still not pretty, but it has the advantage that it is only needed
for when more than one annotation is used.

It has the disadvantage of preventing (int,str) being an alias for

Actually, I don't care that much what particular solution is used to
allow type annotations and non-type annotations to coexist, but I find
it important that is possible.

More information about the Python-ideas mailing list