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

[Dennis Brakhane]

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
does.

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,
wobble(True))

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
Tuple[int,str].


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.