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

[alister]

On Sun, 16 Apr 2017 14:27:28 +1000, Steve D'Aprano wrote:

> 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!"

I think you have (deliberately?) miss understood RR
by optional Static typing I think he means you don't have to use it as is 
in suing static types is optional)  but when you define a variable as 
static then its type is fixed, not simply a hint.

whether or not this could increase code deficiency or complicate the 
compiler further I have no idea




-- 
Fay: The British police force used to be run by men of integrity.
Truscott: That is a mistake which has been rectified.
		-- Joe Orton, "Loot"