PEP 526 - var annotations and the spirit of python

[Schachner, Joseph]

It is interesting to contemplate how this could transform Python into nearly a statically typed language:
x = 3
x = f(x)

If you say the type checker should infer that x is an int, and then therefore complain about x=f(x) if f() does not return an int, then we have what in new C++ is auto type declaration by default, and after that it's statically typed.

So this would still work
valStr = QueryMeasuringInstrument("app.Meas.P1.Result.Mean")
val = float(valStr)

but this would not:
val = QueryMeasuringInstrument("app.Meas.P1.Result.Mean")
val = float(val)
even though it works today in both Python 2 and Python 3.   I don't think the intent of var annotations is to automatically extract the type for variables that are not annotated, and then insist that they retain the same type at all times.   It would break this example.

I think if I do annotate a variable, THEN the type checker can insist that I do not change its type.  So this could cause an error:

string val = QueryMeasuringInstrument("app.Meas.P1.Result.Mean")
val = float(val)

--- Joe S. 

-----Original Message-----
From: Steven D'Aprano <steve+comp.lang.python at pearwood.info> 
Sent: Wednesday, July 4, 2018 11:31 AM
To: python-list at python.org
Subject: Re: PEP 526 - var annotations and the spirit of python

On Wed, 04 Jul 2018 13:48:26 +0100, Bart wrote:

> Presumably one type hint applies for the whole scope of the variable, 
> not just the one assignment.

You know how in C you can write 

    int x = 1;  # the type applies for just this one assignment
    x = 2.5;    # perfectly legal, right?


Wait, no, of course you can't do that. Why would you suggest that as even a possibility?

Of course the type (whether inferred or annotated) applies for the entire scope of that variable.


> Which means that here:
> 
>     x: int = 3
>     x = f(x)
> 
> you know x should still an int after these two statements, because the
> type hint says so. Without it:
> 
>     x = 3
>     x = f(x)
> 
> x could be anything.

That's not how type checking works. It makes *no difference* whether the 
type is inferred or hinted. Type hints only exist to cover the cases the 
type inference engine can't determine, or determine too strictly. See 
below.

In the Dark Ages of type-checking, the compiler was too dumb to work out 
for itself what the type of variables is, so you have to explicitly 
declare them all, even the most obvious ones. Given such a declaration:

    int x = 3;  # using C syntax

the type checker is smart enough to look at the next line:

    x = f(x);

and complain with a type-error if f() returns (say) a string, or a list. 
Checking that the types are compatible is the whole point of type 
checking.

Now fast forward to the Enlightenment of type-inference, first used in a 
programming language in 1973 (so older than half the programmers alive 
today). That purpose doesn't go away because we're using type inference.

With type-inference, the type-checker is smart enough to recognise what 
type a variable is supposed to be (at least sometimes):

    x = 3;  # of course it's an int, what else could it be?
    x = f(x);

and likewise complain if f(x) returns something other than an int. 
There's no point in type checking if you don't, you know, actually 
*check* the types.

With type inference, the only reason to declare a variable's type is if 
the type checker can't infer it from the code, or if it infers the wrong 
type. (More on this later.)

To do otherwise is as pointless and annoying as those comments which 
merely repeat what the code does:

    import math       # import the math module
    mylist.append(v)  # append v to mylist
    counter += 1      # add 1 to counter
    s = s.upper()     # convert s to uppercase
    x: int = 3        # assign the int 3 to x

Don't be That Guy who writes comments stating the bleeding obvious.

There's not always enough information for the type checker to infer the 
right type. Sometimes the information simply isn't there:

    x = []  # a list of what?

and sometimes you actually did intend what looks like a type-error to the 
checker:

    x = 3       # okay, x is intended to be an int
    x = "spam"  # wait, this can't be right
    

In the later case, you can annotate the variable with the most general 
"any type at all" type:

    from typing import Any
    x: Any = 3  # x can be anything, but happens to be an int now
    x = "spam"  # oh that's fine then


or you can simply not check that module. (Type checking is optional, not 
mandatory.)



>> A better example would be:
>> 
>>      x: int = None
>> 
>> which ought to be read as "x is an int, or None, and it's currently
>> None".
> 
> In that case the type hint is lying.

"Practicality beats purity."

"This type, or None" is such a common pattern that any half-way decent 
type checker ought to be able to recognise it. You can, of course, 
explicitly annotate it:

    x: Optional[int] = None

but the type checker should infer that if you assign None to a variable 
which is declared int, you must have meant Optional[int] rather than just 
int. If it doesn't, get a better type checker.

Note that None is a special case (because sometimes special cases *are* 
special enough to break the rules). This should be an error:

    x: int = "hello world"  # wait, that's not an int

But this is fine:

    x: Union[int, str] = "hello world"

x is permitted to be an int or a string, and it happens to currently be a 
string.


> If both x and y have type hints of 'int', then with this:
> 
>     z = x + y
> 
> you might infer that z will be also 'int'

Indeed. If you inferred that z was a list, you're doing it wrong :-)


> (whether it it type hinted or not). But if either of x and y can 
> be None, then this might not even execute.

If x or y could be None, the type checker should complain that None does 
not support the + operator. The whole point of type checking is to find 
bugs like that at compile time. A type checker that doesn't, you know, 
*actually find type bugs* is a waste of time and effort.

This is Type-Checking 101 stuff. A type checker which can't even 
recognise that None+1 is a type error is a pretty crappy type checker. 
Why do you assume that the state of the art in type-checkers in 2018 is 
*worse* than the state of the art in 1953 when Fortran came out?



> If something is an int, then make it an int:
> 
>     x: int = 0

Indeed, that's often the best way, except for the redundant type hint, 
which makes you That Guy:

    x: int = 0  # set x to the int 0


But the point of my example was that x is not an int. It is an optional 
int, that is, an int or None.





-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson