Python is DOOMED! Again!

[Chris Kaynor]

On Thu, Jan 29, 2015 at 2:57 PM, BartC <bc at freeuk.com> wrote:
> 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?

Check out the rationale part of the PEP:
https://www.python.org/dev/peps/pep-0484/#rationale-and-goals. Other
parts of the PEP also answer many of the other questions you have.
I've put in my understandings and opinions below, however.


There are a few perceived advantages to adding type-hints, some of
which are more pie-in-the-sky while others are very likely:
- IDEs can use them to provide better auto-complete.
- Static checkers can do a better job of checking for program
correctness (by erroring if the type-hints are obviously broken).
- Possibility of performance improvements, although CPython (the
official Python interpreter) will still be required to work if the
type-hints are wrong.

> 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?

CPython will, initially, do nothing special with the type-hints that
it does not currently do with the existing annotations, which is
merely parse them and ensure they meet the syntax requirements. My
understanding is that there will be a static checker (possibly derived
from MyPy) that will be endorsed, however, and possibly included in
the STD.

> 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.

As a rule, breaking the type-hint promises will have no effect on the
run-time. Some implementations (Cython or PyPy) may decide to use the
type-hints to guide optimization, perhaps by creating a fast path for
if the promises are met, however conforming implementations cannot
rely on them being correct. PyPy, for example, could JIT the function
presuming the types are right, therefore front-loading the JIT time.
I'm not saying they WILL, just that they COULD.

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

See above. The current plan is not to generally use the hinting at
run-time, but only during static checking of the code. For cases like
PyPy, they already have to do run-time type checking to ensure
correctness when running optimized paths.

> 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.

Regarding the maintenance of type-hints, for people who heavily use
them, I would imagine they will have a static checker setup which will
regularly run and generally produce an error if the hints are not
updated. Most other people will likely only lightly use the type-hints
and may not use static checkers, and thus they probably will get out
of sync. With such a feature, my main use case would be to aid IDEs in
providing auto-complete, which I've done in the past by adding lines
like "if 0: assert isinstance(variable, type)". Most of the functions
I write do not have any such "hints" but instead I've only generally
used it in cases where the type is pretty much fixed, but is a custom
type with a more complicated API.

For the most part, I would almost never use the union types. From past
experience (from languages like C++ and C#), such tends to vastly over
complicate the definitions. The same applies to most cases of generic
types (think list, tuple, set, dict).

> 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.)

My understanding is that you would generally use one of "int",
"float", "Decimal", "Rational", "complex", etc. - basically the name
of the classes themselves. There are some special rules for more
complicated cases, such as forward definitions or various union types.


Chris