On 2 September 2016 at 18:17, Guido van Rossum <gu...@python.org> wrote: > 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).
This is a good point. I totally agree. -- Ivan
_______________________________________________ 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
