<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jan 21, 2015 at 2:18 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">Guido van Rossum wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.<br>
</blockquote>
<br></span>
Wouldn't the static type checker catch that even earlier?<br>
If you reference something in a type expression that you<br>
haven't imported, the static checker won't know what it<br>
means, so surely it must complain.<span class=""><br></span></blockquote><div><br></div><div>But the static checker is like a linter and it's common to run those infrequently (e.g. only when submitting a diff for review) while running unittests frequently (e.g. whenever the developer has written some new code). Assuming you have fast unittests.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.<br>
</blockquote>
<br></span>
I don't see how it's any more magical than '==' being a<br>
distinct token rather than just two '=' tokens in a row,<br>
and 'x == 2' having a different meaning from 'x = 2'.<span class=""><br></span></blockquote><div><br></div><div>It's different because == is used in nearly all languages in common use (certainly all in the TIOBE top 10) while :: would be a brand new invention here (unrelated to e.g. C++'s :: scoping operator).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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>
</blockquote>
<br></span>
I think it's tragic that we seem to have painted ourselves<br>
into a corner where we can't give that winning syntax the<br>
semantics that would be best for what we've now decided on<br>
as the winning use case.<br></blockquote><div><br></div><div>To the contrary, I don't think it's tragic at all. It's how most Python evolution happens. mypy wouldn't have happened the way it did if we didn't have annotations: Jukka's original plan was a custom language, which would have made it just one more Ph.D. project without any users.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
How about we just deprecate relying on run-time evaluation<br>
of argument annotations? You've pretty much declared that<br>
all existing uses of them are deprecated, so it wouldn't<br>
cause much more breakage in the long run, and it would give<br>
us a way out of the corner in the future if we wanted.<span class=""><font color="#888888"></font></span></blockquote><div><br></div><div>I don't see a way to get there from here. Talking about deprecating them is cheap -- actually breaking the code can't happen until 3.6 at the earliest (if we were to issue deprecation warnings by default in 3.5 for every annotation that's not a class or imported from typing), or 3.7 realistically (if in 3.5 we document the deprecation but don't act on it). The provisional status of PEP 484 makes even the more conservative scenario unlikely.<br><br></div><div>And, having coded up much of a possible typing.py module already (<a href="https://github.com/ambv/typehinting/tree/master/prototyping">https://github.com/ambv/typehinting/tree/master/prototyping</a>) I really don't see the big problem with run-time evaluation of constraints.<br></div></div><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)</div>
</div></div>