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

Guido van Rossum guido at python.org
Thu Sep 1 10:46:38 EDT 2016

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 @slottedattributes 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)

More information about the Python-Dev mailing list