Type hinting in Python is so ugly that I stripped it all out after a few days of using it on some personal projects. They more than double the length of function signatures and create comment clutter (is this a real comment or some MyPy flag?).
I wish there was a way to fully separate the hints into separate files. Such files could act like header files in C. Or, some comment character other than # to start type hint (how about "!"?), so IDEs can hide them if the user wants.
Yeah, it seems strange to force people to use type hints when it has had such a mixed reception. I really tried to use type hints with a new project a few months ago, but ended up stripping it all out again because it's just so damn ugly. I wish it were possible to fully define type hints in a separate file for linters, and not mix it in with production code. It's kind of possible to do it, but not fully [1], and mixing type hints inline and in separate files is in my opinion even worse than one or the other.
It is a pity the type hinting is done in a separate file though, as it leads to a lot of duplication. In this case, I pretty much prefer Python’s approach.
I'm currently working in a Python codebase that I love specifically because it uses type hints judiciously. They're particularly useful when you're calling a library function that has an unexpected return type, and particularly useless when you're passing around a string that's obviously a string.
I don't understand why anyone would want type hints. It makes the code so ugly and complex. Pythons appeal for me was always that it is "runnable pseudocode" with a strong object system and great libraries.
To me it feels like python is running as far away from simplicity as fast as possible.
I find it best to see type hinting as "living documentation". Yeah, you can ignore it, it is Python afterall, but if you want the IDE/tools to have better more helpful hints ... use machine readable hint documentation.
I'd argue if your functions are full of type-assert like guards, _then_ use another language!
Yeah I've found when trying (and failing mostly) to convince Python developers to use type hints that they often think it's only to fix bugs and then resist because a) of course their code doesn't have bugs, and b) they've already written their code and discovered lots of bugs painfully at runtime, so they wouldn't get most of the bug-finding benefits anyway.
They never appreciate that type hints make code easier to read and write and navigate and understand and maintain.
Often it's Vim users that have never used a good IDE.
I agree with you, although I must say that as an occasional Python user the way type hints are implemented absolutely baffles me. In particular the fact that they are completely ignored by the standard implementation. They're glorified comments.
Given how opinionated the Python maintainers can be, it baffles me that they accepted to get these optional, noisy, half backed type hints into the core language.
In my experience given that they're optional and you'll almost never get 100% of your code and its dependencies with correct and up to date signatures it's just a nuisance. Maybe in the right projects if all the devs are very thorough with them it can be helpful, but that's really not my experience. If at least it triggered an assertion at runtime when the type doesn't match it would be massively more useful. And even then, if you're so thorough with your typing, why not just use a proper statically typed language?
I really don't get why it's even there to be honest.
In a language like Python that encourages duck typing, type hints can become extremely complex [1] and can get in the way of the ideal of "executable pseudocode" [2].
> Types hints are a terrible non-pythonic kludge to solve a people problem in code.
I have a love/hate relationship with type hinting in Python. I've been using them for about 2 years, and it still just feels... unnatural. I usually add enough so that my IDE (PyCharm) has better autocomplete and that any Sphinx generated docs have sufficient coverage of types I may have missed when adding @params.
I’ve certainly avoided a nasty bug or two with Python type hints without an IDE. Not sure why you’re so hostile to the idea, the OP didn’t say everyone must use them, just that it’s helpful to be familiar with them.
Bingo. I think a big explanation of the wide variance on opinion about type hints is due to reliance on tooling, or lack thereof.
Writing type hinted python in Pycharm or Ipython feels like racing in a sports car. Without it, feels like stop and go traffic with the occasional car accident.
I can see how if you are using a WYSIWYG editor, type hints feel like more text for little gain. But even then, it really helps document intent. In fact switching to IDEs is partly what made me go from someone who hated static typing to loving it.
Good progress. I think you'd be mad to not use type hints, even for small scripts they're hugely advantageous. It's especially nice now that VSCode supports them well.
The only problems I have with them are that they are completely ignored by Python itself - you have to run a separate type checker. That's a fairly stone-aged system. And also I with VSCode had something like Typescript's "no implicit any" so it was more obvious where you had to put types that couldn't be inferred.
I wish there was a way to fully separate the hints into separate files. Such files could act like header files in C. Or, some comment character other than # to start type hint (how about "!"?), so IDEs can hide them if the user wants.
reply