Re: Type hints -- a mediocre programmer's reaction

On Apr 20, 2015, at 11:30 AM, Harry Percival <hjwp2@cantab.net> wrote:

> I think:
> - type hints are ugly

Making them work with the current Python syntax was a challenge. Granted, the end result is not
perfect. It can be improved *if* type hints prove to be generally useful and popular. This might
not happen.

> - they make the language harder to understand
> - particularly for beginners

A counter-point to that would be that good APIs already expose this information but using informal
languages in docstrings, pure comments or straight API documentation. This only standardizes the
notation in a way that:
- let’s those annotations be accessed at runtime
- let’s the entire Python ecosystem learn to read them statically and use them for REPL, IDE
completion and type checking
- moves them to a place where it’s less likely that they become outdated

>     def zipmap(f: Callable[[int, int], int], xx: List[int],
>                yy: List[int]) -> List[Tuple[int, int, int]]:
> 

Yeah, so agreed, this is pretty busy. For such cases, reformatting makes it less confusing (see:
Screenshot 1).



As already stated, you can also name the types, in which case they’re less busy. That’s a
compomise, too, since they require indirection when reading.

> No doubt this has occurred to everyone that's been working on them.  There is a cost. But the
benefits make it worthwhile.

Yes, they start to read more transparently after a while.

> It sounds like the people that will benefit are Google and other "Enterprise" users, IDE vendors,
and the people that will pay for it in sweat and confusion are beginners and John Q. Mediocre
Programmer.

Any startup that at the beginning bangs out code as fast as possible - and eventually *becomes
successful* - will be happy to be able to introduce gradual typing as a measure of improving
quality.

> My worry is that once type hinting gets standardised, then they will become a "best practice”

For library authors and APIs, they might. There’s nothing alarming with that, as I said, for
those use cases you already expect “type hints” in the form of docstrings, comments, API docs,
tests, etc.

> there's a particular personality type out there that's going to start wanting to add type hints
to every function they write. Similarly to mindlessly obeying PEP8 while ignoring its intentions,
hobgoblin-of-little-minds style, I think we're very likely to see type hints appearing in a lot of
python source, or a lot of pre-commit-hook checkers.

Yes, this is going to happen sometimes. If you can’t fight a hobgoblin in your
community/organization, you’ve got bigger problems than ugly hints. Ultimately, we can’t
optimize for the lowest common denominator.

> Pretty soon it will be hard to find any open source library code that doesn't have type hints, or
any project style guide that doesn't require them.

Harry, you must be the biggest Python 3 supporter ever <3 More seriously, no, this is not going to
happen fast.

> Sounds great right?  Everybody will be happy!  So let's nail it down!

Stub files have many downsides, too, unfortunately:
- we don’t *want* to have them, but we *need* to have them (C extensions, third-party modules,
Python 2, …)
- they bring cognitive overhead of having to switch between two files
- they require the author to repeat himself quite a lot
- they might go out of date much easier than annotations in the function signature
- they can’t help with local variable inference

Since it was mentioned in a different e-mail in this thread: yes, the standard library is not
getting any type annotations. When we decide to ship type hints with Python 3.6, they will be added
as stubs.

As for the actual proposal:

> * standardise the syntax for type hints in 3.5, as per PEP484
> * but: recommend the use of stub files as the preferred place to store hints
> * and: deprecate function annotations in the core language
> * remove them from the core language altogether in 3.6

That is still pretty radical. I’ll leave the final words to the other authors of PEP 484 but from
my perspective it’s not type annotations that are ugly, it’s the stubs. The annotation syntax
might be improved for future releases. Stubs - by design - will always be inferior because of the
reasons stated above.

-- 
Best regards,
Łukasz Langa

WWW: http://lukasz.langa.pl/
Twitter: @llanga
IRC: ambv on #python-dev