Python is DOOMED! Again!

[BartC]

On 22/01/2015 04:30, Steven D'Aprano wrote:

> https://www.python.org/dev/peps/pep-0484/

> Here's a potential real-world example, from the statistics module in Python
> 3.4, before and after adding annotations:
>
> def median_grouped(data, interval=1): ...
>
> def median_grouped(data:Iterable[Real], interval:Real=1)->Real: ...

> So how does Python's proposed type-hints compared to that used by other
> languages?

> C:
>
>    double
>    median_grouped (IterableOfReal data, double interval)

> I think it is clear that Python's annotation syntax remains quite close to
> executable pseudo-code. Fears that type-hints will doom Python are not
> credible.

I've read most of the thread but haven't been able to figure out /why/ 
this is being proposed. What is the advantage, speed?

And how does it work in practice: is it necessary to use a special 
Python interpreter to gain the advantage, or do you only get a benefit 
after putting the source through some sort of compiler system?

I can understand many of the misgivings. I have a dynamic language of my 
own, to which I've tried adding type hinting a few times, but in the end 
decided to get rid of those type hints and keep things purer and simpler 
(and a hell of a lot easier to implement too).

There was also something unsatisfactory about having to help things 
along by putting in explicit hints, which also cause trouble: what 
happens when the promise you make are wrong? It would mean putting in 
extra checking code to make sure things are what you said.

So when assigning a non-hinted variable to a hinted one, it needs to be 
type-checked, otherwise things can go wrong internally. So far from 
making things faster, it starts by slowing them down!

Putting in hints, (as as I implemented them using primitive types), 
meant that functions and code no longer worked in a generic (or 
polymorphic) manner. Code also changes, but the type hints aren't 
maintained. I understand the Python proposal allows type hints to be a 
union of expected types, but that sounds complicated.

Depending on how it's implemented, it also seems to me that a program 
with type hints might work with a Python implementation that ignores the 
hints, but might not work with one that makes use of the hints (because 
of using a value that is not of the hinted type).

Also, how does it work with numeric types; is there just one numeric 
type, or two (integer and real) or more? With more than one numeric type 
hint, it's going to be a headache trying to determine what the result of 
a function can be. (And if you have to choose real because 1% of the 
time the result will be real, then you lose the advantage of being able 
to work with integers 99% of the time.)

-- 
Bartc