On Sun, 16 Apr 2017 09:48:15 +0000, alister wrote:
> 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
Actually isn't this a feature of cython?
--
Armadillo:
To provide weapons to a Spanish pickle.
--
https://mail.python.org/mailman/listinfo/python-list
