On Apr 20, 2015, at 11:30 AM, Harry Percival <hj...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
