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