<div dir="ltr"><div>On 2 September 2016 at 18:17, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>> On Fri, Sep 2, 2016 at 6:43 AM, Ivan Levkivskyi <<a href="mailto:levkivskyi@gmail.com">levkivskyi@gmail.com</a>> wrote:<br>> > On 2 September 2016 at 04:38, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>> >> However, a standalone Ellipsis doesn't currently have a meaning as a<br>> >> type annotation (it's only meaningful when subscripting Tuple and<br>> >> Callable), so a spelling like this might work:<br>> >><br>> >>     NAME: ...<br>> >><br>> >> That spelling could then also be used in function definitions to say<br>> >> "infer the return type from the return statements rather than assuming<br>> >> Any"<br>> ><br>> > Interesting idea.<br>> > This is somehow similar to one of the existing use of Ellipsis: in numpy it<br>> > infers how many dimensions needs to have the full slice, it is like saying<br>> > "You know what I mean". So I am +1 on this solution.<br>><br>> I like it too, but I think it's better to leave any firm promises<br>> about the *semantics* of variable annotations out of the PEP. I just<br>> spoke to someone who noted that the PEP is likely to evoke an outsize<br>> emotional response. (Similar to what happened with PEP 484.)<br>><br>> Pinning down the semantics is not why I am pushing for PEP 526 -- I<br>> only want to pin down the *syntax* to the point where we won't have to<br>> change it again for many versions, since it's much harder to change<br>> the syntax than it is to change the behavior of type checkers (which<br>> have fewer backwards compatibility constraints, a faster release<br>> cycle, and narrower user bases than core Python itself).<br><br>This is a good point. I totally agree.<br><br>--<br></div>Ivan<br><br></div>