<div dir="ltr"><div><div><div>Hi all,<br><br></div><div>tldr; type hints in python source are scary. Would reserving them for stub files be better?<br></div><div><br></div>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.<br><br></div><div>So, in outline:<br><br></div><div>I think:<br></div><div>- type hints are ugly<br></div><div>- they make the language harder to understand<br></div><div>- particularly for beginners<br></div><div>- the defense that "they're optional" doesn't really work, for several reasons.<br></div><div>- but maybe there's a way to keep them and their benefits, without incurring the above costs<br></div><div><br><br></div><div>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):<br><br>    def zipmap(f: Callable[[int, int], int], xx: List[int],<br>               yy: List[int]) -> List[Tuple[int, int, int]]:<br></div><div><br></div><div>arg.  and imagine it with default arguments.<br><br>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.<br><br></div><div>No doubt this has occurred to everyone that's been working on them.  There is a cost. But the benefits make it worthwhile.<br><br></div><div>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.<br><br></div><div>But what I really want to dwell on are the costs.  <br><br><br></div><div>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.<br><br></div><div>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.<br><br></div><div>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.<br></div><br></div><div>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.<br><br></div><div>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.<br><br></div><div>That sounds like the best of both worlds to me.<br></div><div>- .py files stay beautiful, concise, and easy to read.<br></div><div>- beginners don't have to worry about wading through type definitions when they find themselves browsing someone else's source<br></div><div>- type information is available to the linters and static file checkers, so we get all the benefits.<br><br></div><div>Sounds great right?  Everybody will be happy!  So let's nail it down! If I was in charge, here's what I'd do:<br><br></div><div>* standardise the syntax for type hints in 3.5, as per PEP484<br></div><div>* but: recommend the use of stub files as the preferred place to store hints<br></div><div>* and: deprecate function annotations in the core language<br></div><div>* remove them from the core language altogether in 3.6<br><br></div><div>How about that?<br><br></div><div>HP</div><br><br><br><div><br></div></div>