<div dir="ltr">On 4 September 2016 at 18:43, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 4 September 2016 at 21:32, Ivan Levkivskyi <<a href="mailto:levkivskyi@gmail.com">levkivskyi@gmail.com</a>> wrote:<br>
> The first form still could be interpreted by type checkers<br>
> as annotation for value (a cast to more precise type):<br>
><br>
> variable = cast(annotation, value) # visually also looks similar<br>
<br>
</span>I think a function based spelling needs to be discussed further, as it<br>
seems to me that at least some of the goals of the PEP could be met<br>
with a suitable definition of "cast" and "declare", with no syntactic<br>
changes to Python. Specifically, consider:<br>
<br>
def cast(value, annotation):<br>
return value<br>
<br>
def declare(annotation):<br>
return object()<br></blockquote><div> <br></div><div>Nick, If I understand you correctly, this idea is very similar to Undefined.<br>It was proposed a year and half ago, when PEP 484 was discussed.<br><br></div><div>At that time it was abandoned, it reappeared during the discussion<br></div><div>of this PEP, but many people (including me) didn't like this,<br>so that we decided to put it in the list of rejected ideas to this PEP.<br><br></div><div>Some downsides of this approach:<br><br></div><div>* People will start to expect Undefined (or whatever is returned by declare()) <br>everywhere (as in Javascript) even if we prohibit this.<br><br></div><div>* Some runtime overhead is still present: annotation gets evaluated<br></div><div>at every call to cast, and many annotations involve creation of<br>class objects (especially generics) that are very costly.<br></div><div>Because of this overhead, such use of generics was prohibited in PEP 484:<br><br></div><div>x = Node[int]() # prohibited by PEP 484<br></div><div>x = Node() # type: Node[int] # this was allowed<br></div><div><br></div><div>* Readability will be probably even worse than with comments:<br></div><div>many types already have brackets and parens, so that two more form cast()<br></div><div>is not good. Plus some noise of the if 0: that you mentioned, plus<br></div><div>"cast" everywhere.<br></div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
However, exploring this possibility still seems like a good idea to<br>
me, as it should allow many of the currently thorny semantic questions<br>
to be resolved, and a future syntax-only PEP for 3.7+ can just be<br>
about defining syntactic sugar for semantics that can (by then)<br>
already be expressed via appropriate initialisers.<br></blockquote></div><br></div><div class="gmail_extra">I think that motivation of the PEP is exactly opposite, this is why it has<br></div><div class="gmail_extra">"Syntax" not "Semantics" in title. Also quoting Guido:<br></div><div class="gmail_extra"><br>> But I'm not in a hurry for that -- I'm only hoping to get the basic<br>
> syntax accepted by Python 3.6 beta 1 so that we can start using this<br>
> in 5 <span class="gmail-il">years</span> from now rather than <span class="gmail-il">7</span> <span class="gmail-il">years</span> from now.<br><br></div><div class="gmail_extra">I also think that semantics should be up to the type checkers.<br></div><div class="gmail_extra">Maybe it is not a perfect comparison, but prohibiting all type semantics<br></div><div class="gmail_extra">except one is like prohibiting all Python web frameworks except one.<br></div><div class="gmail_extra"><br>--<br></div><div class="gmail_extra">Ivan<br><br></div></div>