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

Guido van Rossum guido at python.org
Fri Sep 2 12:17:53 EDT 2016


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).

-- 
--Guido van Rossum (python.org/~guido)


More information about the Python-Dev mailing list