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

[Guido van Rossum]

On Tue, Aug 30, 2016 at 7:44 PM, Jack Diederich <jackdied at gmail.com> wrote:
> +0. We should try and be consistent even if this is a thing I don't want.
> And trust me, I don't!

No problem. You won't have to!

> That said, as long as pro-mypy people are willing to make everyone else pay
> a mypy reading tax for code let's try and reduce the cognitive burden.
>
> * Duplicate type annotations should be a syntax error.
>   Duplicate annotations aren't possible in functions so that wasn't an issue
> in 484. 526 makes some things syntax errors and some things runtime errors
> (for good reason -- function bodies aren't evaluated right away).
> Double-annotating a variable is something we can figure out at compile time
> and doing the double annotating is non-sensical so we should error on it
> because we can.

Actually I'm not so sure that double-annotating is always nonsensical.
In the mypy tracker we're seeing some requests for type *inference*
that allows a variable to be given another type later, e.g.

    x = 'abc'
    test_func(x)
    x = 42
    another_test_func(x)

Maybe there's a use for explicit annotations too. I would rather not
get in the way of letting type checkers decide such semantics.

> *  Dissallowing annotations on global and nonlocal
>   Agreed, allowing it would be confusing because it would either be a
> re-definition or a hard to read annotation-at-a-distance.
>
> * Where __annotations__ live
>   It is strange to allow modules.__annotations__ and MyClass.__annotations__
> but not myfunc.__annotations__ (or more in line with existing function
> implementations a myfunc.__code__.co_annotations). If we know enough from
> the syntax parse to have func.__code__.co_varnames be known then we should
> try to do that with annotations.  Let's raise a SyntaxError for function
> body annotations that conflict with same-named variables that are annotated
> in the function signature as well.

But myfunc.__annotations__ already exists -- PEP 3107 puts the
signature annotations there. The problem with co_annotations is that
annotations are evaluated (they can be quite complex expressions, e.g.
Optional[Tuple[int, int, some_mod.SomeClass]]), while co_varnames is
just a list of strings. And code objects must be immutable. The issue
with rejecting duplicate annotations so sternly is the same as for the
previous bullet.

> I did C++ for years before I did Python and wrote C++ in many languages
> (including Python). So ideally I'm -1000 on all this stuff for cultural
> reasons -- if you let a C++ person add types they will for false comfort.
> But again, I'm +0 on this specific proposal because we have already gone
> down the garden path.

As long as you run mypy the comfort shouldn't be false. (But your
starting with C++ before Python explains a lot. :-)

> -Jack

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