Static typing [was Re: Python and the need for speed]

[Steve D'Aprano]

On Sat, 15 Apr 2017 11:55 am, Rick Johnson wrote:

> apparently, the py-devs believe we
> only deserve type declarations that do nothing to speed up
> code execution (aka: type-hints), instead of type
> declarations that could actually speed up the code. Go
> figure!
> 
> I'm not a fan of forced static typing, but i am a fan of
> optional static typing.

Are you aware that optional static typing CANNOT be used for optimization?

Since it is *optional*, it is only a hint, not a fact. You can tell the
compiler that you believe that n will be an int, but it's not guaranteed.
As the Dude says, the type hint is 

    that's, like, only your opinion man

and the compiler cannot trust it. It must still guard the operation with a
runtime check that n actually is an int, and so you lose most or all of the
benefit of telling the compiler that it's an int.

There are clever Just In Time compiler tricks that can optimize the code,
which is what Psycho did and PyPy still does, but they don't need type
hints. Type hints are superfluous to a JIT compiler, since it already knows
the runtime type information. But JIT compilers have their limitations,
like the necessity of warm up time, increased complexity, and much heavier
memory requirements.

If you want to use type hints for the purposes of compile-time
optimizations, then typing must be compulsory and enforced by the compiler.
No longer optional hints, but mandatory statements of indisputable fact.

(That doesn't necessarily mean that you have to use type declarations, like
in C, Pascal and Java. A good modern compiler can infer types, like in ML
and Haskell.)

Python's gradual typing is not about optimization, it is about testing
program correctness and helping to find bugs at compile time*. As such, the
fact that type hints are optional and "only your opinion" doesn't matter.
The promise made by the type checker is:

    IF what you say is true (the type hints are correct)
    THEN this code will be sound

(or alternatively, it's unsound because you have a type mismatch, and get a
compile-time error). As a fallback, you still have the runtime dynamic type
checks.

Unit and functional tests are great, and necessary. Just because your code
compiles in C, Java or Pascal doesn't mean that it is correct. You still
have to run the code and test that it does what you expect.

"It compiles! Quick, ship it!" -- attributed to Microsoft developers

Nevertheless, the problem with testing is that it can only prove the
presence of bugs, not their absence. A test that fails proves that your
code has at least one bug. A test that passes doesn't prove that there are
no bugs.

Static type checking helps to shrink the gap between "all of my tests pass,
so there are no known bugs" and "there are no unknown bugs". And that's an
important and powerful tool, especially for large and complex programs.

Python's type-hints are for writing correct code, not fast code. I find it
amusing when people argue that Python's type hints are pointless or
useless. Do they realise they're effectively arguing that correct, bug-free
code is pointless?

"Your code is buggy. It calculates the wrong result."

"Maybe so, but look how fast it does it!"




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.