[Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

[Ivan Levkivskyi]

On 2 September 2016 at 18:17, Guido van Rossum <guido at python.org> wrote:
> On Fri, Sep 2, 2016 at 6:43 AM, Ivan Levkivskyi <levkivskyi at gmail.com>
wrote:
> > On 2 September 2016 at 04:38, Nick Coghlan <ncoghlan at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160902/3a099d16/attachment.html>