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

[Guido van Rossum]

On Thu, Sep 1, 2016 at 6:11 AM, Koos Zevenhoven <k7hoven at gmail.com> wrote:
> While a large amount of Python programmers may not be interested in
> type hinting local variables inside functions, I can see other
> potential benefits in this.

IOW, PEP 3157 is not dead yet. Indeed.

> When I start sketching a new class, I'm often tempted to write down
> the names of the attributes first, before starting to implement
> ``__init__``. Sometimes I even write temporary comments for this
> purpose. This syntax would naturally provide a way to sketch the list
> of attributes. Yes, there is already __slots__, but I'm not sure that
> is a good example of readability.

Agreed, it can't get much cleaner than NAME: TYPE.

> Also, when reading code, it may be hard to tell which (instance)
> attributes the class implements. To have these listed in the beginning
> of the class could therefore improve the readability.

Right. That has been my observation using PEP 484's type comments
extensively for annotating instance variables at the class level. E.g.
much of mypy's own code is written this way, and it really is a huge
help. But

    foo = None  # type: List[int]

while it gives me the info I'm looking for, is not great
notation-wise, and that's why I started thinking about an alternative:

    foo: List[int]

(in either case, the __init__ contains something like `self.foo = []`).

> In this light, I'm not sure it's a good idea to allow attribute type
> hints inside methods.

Those are meant for the coding style where all attributes are
initialized in the method and people just want to add annotations
there. This is already in heavy use in some PEP-484-annotated code
bases I know of, using # type comments, and I think it will be easier
to get people to switch to syntactic annotations if they can
mechanically translate those uses. (In fact we are planning an
automatic translator.)

>> - Whether the keyword-free syntax idea proposed here is best:
>>   NAME: TYPE
>>   TARGET: TYPE = VALUE
>
> I wonder if this would be better:
>
> def NAME: TYPE
> def NAME: TYPE = VALUE
>
> Maybe it's just me, but I've always thought 'def' is Python's least
> logically used keyword. It seems to come from 'define', but what is it
> about 'define' that makes it relate to functions only. Adding an
> optional 'def' for other variables might even be a tiny bit of added
> consistency.

Here I strongly disagree. Everyone will be confused.

> Note that we could then also have this:
>
> def NAME
>
> Which would, again for readability (see above), be a way to express
> that "there is an instance variable called X, but no type hint for
> now". I can't think of a *good* way to do this with the keyword-free
> version for people that don't use type hints.
>
> And then there could also be a simple decorator like
> @slotted_attributes that automatically generates "__slots__" from the
> annotations.

This I like, or something like it. It can be a follow-up design. (I.e.
a separate PEP, once we have experiece with PEP 526.)

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