<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 20, 2015 at 9:09 PM, Greg Ewing <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>Andrew Barnert wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But I think there's a hole in the premise. Python's key strength is good<br>
debug-ability and amazingly powerful introspection. (I mean Python's _two_<br>
key strengths are...) Information that has no runtime meaning to the<br>
interpreter may still have meaning to the user who's debugging code,<br>
</blockquote>
<br></span>
There's nothing wrong with making the annotations *available*<br>
at run time. All I'm saying is that *evaluating* them at run<br>
time hinders rather than helping for the intended use.<span><font color="#888888"></font></span></blockquote><div><br></div><div>That's debatable. While evaluating them at run time causes some issues with forward references (mostly for container-ish class definitions), it also catches many mistakes early, such as not importing the referenced classes. Surely if you are reference a class that's not a built-in you have to import it before you can reference in a type hint -- otherwise how would the type checker know where to look for the class definition?<br><br></div><div>FWIW if you really don't want to have them evaluated at run time, you can just put all type hints in string quotes. mypy will treat them as forward references, but AFAIC it doesn't insist that a forward reference contains at least one symbol that is not defined yet at the place where it occurs. :-) I doubt that this style has many things to recommend it though (see previous paragraph).<br></div><div><br>Let me also use this response to explain why I think "::" is a bad idea:<br><br></div><div>- First and foremost, Python usually (an d intentionally!) uses punctuation in a way derived from or similar to long-standing traditions for written text and basic math (with a few going back to old programming conventions, like using * for multiplication). The single colon used for type annotations is an example of this: it is analogous to the way the colon is often used in prose. Switching to a double colon would make it a magical operator -- especially since a single colon in the same position would have a similar but different meaning. Decorator syntax notwithstanding, magical operators are and should remain rare in Python. Eight years ago we picked the winning syntax for argument annotations. It would be tragic if we now were to replace it with this syntactic hack.<br></div><div><br></div><div>- I want the type checker to work for earlier versions of Python 3 as well, so that library maintainers (at least for code that doesn't need to support Python 2) can start including type hints in their code without locking that code in to Python 3.5 -- they can use a backport of the (run time) typing package from PyPI, and the type checker can handle earlier Python versions just fine. (All of this already works for mypy.)<br><br></div><div>- What would you do for function return type hints? "-->" or "->>" or "->:" or "->->" all look completely arbitrary.<br><br></div><div>- Looking ahead, if type hints are successful we might want to add a similar notation to declare the type of variables or class attributes, for example "age: int = 99" or perhaps "var age: int = 99". But if we were to use "::" for type hints in function definitions, for consistency we would have to use "age:: int = 99", which would just perpetuate the syntactic hack.<br></div></div><br>-- <br><div>--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>