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

Guido van Rossum guido at python.org
Fri Jan 16 22:40:15 CET 2015

On Fri, Jan 16, 2015 at 12:34 PM, Dennis Brakhane <brakhane at googlemail.com>

> 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 cleanest way to do this would be to use decorators for the
non-type-hint use case.

> > 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's very ambiguous though. Especially since plain strings are taken to be
type annotations (used for forward references).

> It has the disadvantage of preventing (int,str) being an alias for
> Tuple[int,str].

But we're not proposing that (overloading native container syntax for types
was proposed and rejected early on).

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


--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150116/c0638ec5/attachment.html>

More information about the Python-ideas mailing list