Hi all,
tldr; type hints in python source are scary. Would reserving them for stub
files be better?
For people that don't know me (most of you I think), I don't have a long
experience of programming (perhaps 5 years, barring a bit of messing about
with BASIC in the 80s), I've never made any commits on cPython, and so I
don't speak from a great height of experience. I am very much a "mediocre
programmer" (TM). I wouldn't have felt it appropriate to email python-dev
about this, except that one of the members encouraged me to do so --
perhaps they felt there hadn't been enough "balance" in discussions to
date. Also, I've had enough positive reactions in person and on the
twitters from people well-known in the Python community, to make me feel
like maybe the issue is at least worth discussing... And I do have some
experience with teaching Python to beginners, enough to worry about
anything I think might make their lives more difficult.
So, in outline:
I think:
- type hints are ugly
- they make the language harder to understand
- particularly for beginners
- the defense that "they're optional" doesn't really work, for several
reasons.
- but maybe there's a way to keep them and their benefits, without
incurring the above costs
My first reaction to type hints was "yuck", and I'm sure I'm not the only
one to think that. viz (from some pycon slides):
def zipmap(f: Callable[[int, int], int], xx: List[int],
yy: List[int]) -> List[Tuple[int, int, int]]:
arg. and imagine it with default arguments.
Of course, part of this reaction is just a knee-jerk reaction to the new
and unfamiliar, and should be dismissed, entirely justifiably, as mere
irrationality. But I'm sure sensible people agree that they do make our
function definitions longer, more complex, and harder to read.
No doubt this has occurred to everyone that's been working on them. There
is a cost. But the benefits make it worthwhile.
I don't want to spend too long debating the benefits -- Guido gave an
outline of them at Pycon, and I know y'all wouldn't be doing all this work
for no reason. All I will say is -- 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.
But what I really want to dwell on are the costs.
I've heard this argument that, because the type hints are optional, they're
not something that beginners or the average user needs to worry about.
Beginners won't need to learn them, and they'll probably never see them.
And average users won't need them either, so they don't need to worry about
them either. So the costs are minimal! I should relax.
I'm not so sure. My worry is that once type hinting gets standardised,
then they will become a "best practice", and 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. 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.
It may not even be an irrational, cargo-cult thing -- they really may be
paying dividends. But it does mean we will all have to wade through a bunch
of type hints before we can understand any function. Not the end of the
world. The extra effort may even help us understand our functions better.
But it's just that little bit uglier, just that little extra mental effort,
just that little extra barrier that is going to mean some people, at the
margin, just give up on learning programming, or switch to javascript, or
whatever it'll be.
Now I'm aware that throwing out type hints altogether is unlikely to be a
popular proposal at this stage. So I'm casting around for an alternative.
And it seems to me that stub files might be the answer.
>From what I understand, type hint files are files with the extension .pyi
that provide stub versions of the functions in the matching .py files, but
that contain the type hints, while the .py file doesn't. In fact they're
likely to be a very popular approach anyway, since they allow type hints
for codebases that need to work under both 2 and 3.
That sounds like the best of both worlds to me.
- .py files stay beautiful, concise, and easy to read.
- beginners don't have to worry about wading through type definitions when
they find themselves browsing someone else's source
- type information is available to the linters and static file checkers, so
we get all the benefits.
Sounds great right? Everybody will be happy! So let's nail it down! If I
was in charge, here's what I'd do:
* 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
How about that?
HP
_______________________________________________
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
