On Mon, Apr 20, 2015 at 07:30:39PM +0100, Harry Percival wrote: > Hi all, > > tldr; type hints in python source are scary. Would reserving them for stub > files be better?
No no no, a thousand times no it would not! Please excuse my extreme reaction, but over on the python-list mailing list (comp.lang.python if you prefer Usenet) we already had this discussion back in January. Anyone wishing to read those conversations should start here: https://mail.python.org/pipermail/python-list/2015-January/697202.html https://mail.python.org/pipermail/python-list/2015-January/697315.html Be prepared for a long, long, long read. Nothing in your post hasn't already been discussed (except for your proposal to deprecate annotations altogether). So if you feel that I'm giving any of your ideas or concerns short-shrift, I'm not, it's just that I've already given them more time than I can afford. And now I get to do it all again, yay. (When reading those threads, please excuse my occasional snark towards Rick, he is a notorious troll on the list and sometimes I let myself be goaded into somewhat less than professional responses.) While I sympathise with your thought that "it's scary", I think it is misguided and wrong. As a thought-experiment, let us say that we roll back the clock to 1993 or thereabouts, just as Python 1.0 (or so) was about to be released, and Guido proposed adding *default values* to function declarations [assuming they weren't there from the start]. If we were used to Python's clean syntax: def zipmap(f, xx, yy): the thought of having to deal with default values: def zipmap(f=None, xx=(), yy=()): might be scary. Especially since those defaults could be arbitrarily complex expressions. Twenty years on, what should we think about such fears? Type hinting or declarations are extremely common in programming languages, and I'm not just talking about older languages like C and Java. New languages, both dynamic and static, like Cobra, Julia, Haskell, Go, Boo, D, F#, Fantom, Kotlin, Rust and many more include optional or mandatory type declarations. You cannot be a programmer without expecting to deal with type hints/declarations somewhere. As soon as you read code written in other languages (and surely you do that, don't you? you practically cannot escape Java and C code on the internet) and in my opinion Python cannot be a modern language without them. I'm going to respond to your recommendation to use stub files in another post (replying to Barry Warsaw), here I will discuss your concerns first. > 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. You've picked a complex example and written it poorly. I'd say yuck too, but let's use something closer to PEP-8 formatting: def zipmap(f: Callable[[int, int], int], xx: List[int], yy: List[int] ) -> List[Tuple[int, int, int]]: Not quite so bad with each parameter on its own line. It's actually quite readable, once you learn what the annotations mean. Like all new syntax, of course you need to learn it. But the type hints are just regular Python expressions. > 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. Everything has a cost and all features, or lack of features, are a trade-off. Function definitions could be even shorter and simpler and easier to read if we didn't have default values. [...] > 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. I doubt that very much. I'm not a betting man, but if I were, I would put money on it. Firstly: libraries tend to be multi-version, and these days they are often hybrid Python 2 & 3 code. Since annotations are 3 only, libraries cannot use these type hints until they drop support for Python 2.7, which will surely be *no less* than five years away. Probably more like ten. So "annotations everywhere" are, at best, many years away. Secondly, more importantly, there are a lot of Python programmers who (like you) dislike type hinting. They are not going to suddenly jump on the band wagon and use them. Even if the libraries that they use have annotations, most people don't read the source and will never know. But the biggest reason that I know that there will not be a sudden rush to horrible enterprisey code in Python due to type annotations is that Python has allowed enterprisey code for 20+ years and it hasn't become common practice. We can overuse design patterns, and turn everything into a property (or worse, getter/setter methods) just like Java, and we simple don't. Well, perhaps some libraries do. Since we don't tend to read their source code, how would we know if they are full of properties and decorators and metaclasses doing the most horrid things imaginable? All we care about is that the code we write is ordinary readable Python code, and it works. (There may be exceptions, but they are *exceptions*.) There is no epidemic of style guides making properties mandatory, or git check-ins that reject any function that fails to have doctests, or any of the bad things that have been possible in Python for two decades. Type hints can be abused too, and just like all the other things that can be, they won't be abused to the degree you fear. My comments on stub files to follow. -- Steve _______________________________________________ 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
