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

[Terry Reedy]

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.

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.

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

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.

-- 
Terry Jan Reedy