<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Jan 18, 2015 at 4:01 PM, Greg <span dir="ltr"><<a href="mailto:greg.ewing@canterbury.ac.nz" target="_blank">greg.ewing@canterbury.ac.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 19/01/2015 8:34 a.m., Guido van Rossum wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm putting a line in the sand: annotations are<br>
for types<br>
</blockquote>
<br></span>
Do you mean *static* types, or types in general?<br>
<br>
If they're only for static type checking, this seems a waste of a<br>
facility that evaluates things at run time. Moreover, evaluating<br>
them at run time is actually counterproductive, since it makes<br>
dealing with things like forward references unnecessarily awkward.<br>
It also introduces useless runtime overhead. And they only address<br>
part of the problem, since they only apply to functions and not<br>
other things we might want to specify the type of.<br>
<br>
If you've decided that static type checking is important<br>
enough to officially support, how about designing a new language<br>
feature specifically for that?<br>
<br>
We could, for example, borrow Haskell's :: symbol:<br>
<br>
class Duck:<br>
<br>
  num_feathers :: int = 4200<br>
<br>
  def quack(volume :: float)<br>
    ...<br>
<br>
The type expressions following :: would have the form of<br>
Python expressions, but they would not be evaluated.<br>
Introspecting on them at runtime could be supported, but<br>
you would get an AST instead of a value.<span class="HOEnZb"><font color="#888888"></font></span><br></blockquote></div><br></div><div class="gmail_extra">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.<br><br></div><div class="gmail_extra">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.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)</div>
</div></div>