On Sun, Jan 18, 2015 at 4:01 PM, Greg <greg.ewing@canterbury.ac.nz> wrote:

On 19/01/2015 8:34 a.m., Guido van Rossum wrote:

I'm putting a line in the sand: annotations are
for types

Do you mean *static* types, or types in general?

If they're only for static type checking, this seems a waste of a
facility that evaluates things at run time. Moreover, evaluating
them at run time is actually counterproductive, since it makes
dealing with things like forward references unnecessarily awkward.
It also introduces useless runtime overhead. And they only address
part of the problem, since they only apply to functions and not
other things we might want to specify the type of.

If you've decided that static type checking is important
enough to officially support, how about designing a new language
feature specifically for that?

We could, for example, borrow Haskell's :: symbol:

class Duck:

num_feathers :: int = 4200

def quack(volume :: float)
...

The type expressions following :: would have the form of
Python expressions, but they would not be evaluated.
Introspecting on them at runtime could be supported, but
you would get an AST instead of a value.

There is no time to get such a proposal implemented in time for Python 3.5. Since you are proposing entirely new syntax we could still do this later if we ended up finding that the mypy approach after all is not so useful. And abandoning the mypy-based proposal is easy -- the typing module will be provisional in 3.5, so in 3.6 we could just delete it from the stdlib if we decided we took a wrong turn. People who really liked it could still install it from PyPI.

But I don't expect that to happen. I don't see the mypy approach as a waste of facilities evaluated at run time. I have found it a very liberating experience to realize that the type checker could just be a linter and there is an elegant way to avoid noise from the interaction between code that has type annotations and code that doesn't.

--Guido van Rossum (python.org/~guido)