[Python-ideas] Trial balloon: adding variable type declarations in support of PEP 484

[Guido van Rossum]

On Tue, Aug 2, 2016 at 3:55 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> On 8/2/2016 1:14 AM, Guido van Rossum wrote:
>>
>> What makes you respond so vehemently to `a: float`?
>
>
> I am not Gregory, but I also had a negative reaction. It makes no sense to
> me.
>
> By your rule that annotations are optional and ignorable, 'a: float' is a
> statement expression consisting of the identifier 'a'.  If one ignores or
> removes the annotations of a function header, one is left with a valid
> function header with the same meaning.  The only runtime effect is on the
> .annotations attribute, and any consequence of that.  If one were to do the
> same with a (proposed) annotated assignment, would be left with a valid
> assignment, and there should be no runtime effect either way.  If one
> removes ': float' from 'a: float', one is left with 'a', a single-name
> expression statement.  To be consistent, the addition or removed of the
> annotation should  have no runtime effect here either.

You're taking the "optional and ignorable" too literally. My strawman
proposal for the semantics of

  a: float

is that the interpreter should evaluate the expression `float` and
then move on to the next line. That's the same as what happens with
annotations in signatures. (However this is a potential slow-down and
maybe we need to skip it.)

The idea of this syntax is that you can point to function definitions
and hand-wave a bit and say "just like an argument has an optional
type and an optional default, a variable can have either a type or an
initializer or both" (and then in very small print continue to explain
that if you leave out both the two situations differ, and ditto for
multiple assignment and unpacking).

> The meaning is the statement is 'if a is not bound to anything in the
> namespace stack, raise NameError'.  In batch mode, the else part is ignore
> it, ie, 'pass'.  I have never seen a name expression statement used this way
> in non-interactive code.  It would be an obscure way to control program
> flow.
>
> Interactive mode adds 'else print(a)', which is useful, hence '>>> a' is
> common.  This is not relevant to the offline use of annotations.

None of that is relevant, really. :-)

> If 'a' is bound to something, then the annotation belongs on the binding
> statement.  If it is not, then the annotation is irrelevant unless added to
> the NameError message.
>
>
> If, as I suspect. upi meant 'a: float' to be a different kind of statement,
> such as a static type declaration for the name 'a', it would be a major
> change to Python, unlike adding type hints to existing statements.  It would
> make the annotation required, not optional.  It would complicate an
> annotation stripper, as 'a: float' would have to be handled differently from
> 'a: float = 1.0'.

But there are no annotation strippers, only parsers that understand
the various annotation syntaxes and ignore the annotations.

> The existing scope declarations are a bit jarring also, but they have the
> runtime effect of enabling non-local name binding.  The best alternative to
> 'global n' I can think of would have been a tagged '=', such as '=*' meaning
> 'bind in the global namespace.  But this would have had problems both
> initially and when adding augmented assignments and non-local binding.

This is entirely different from global/nonlocal -- the latter are
references to previously declared/initialized variables. Here we are
declaring new local/class/instance variables. Pretty much the
opposite.

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