I'm usually a strict proponent of static typing, but I discovered that for the things I use Python for (mostly quick'n'dirty cross-platform scripting, not "real programs") it's indeed quite a nuisance mainly for non-trivial cases where the type hints looked entirely too complex and 'dominated' the code way too much resulting in (paradoxically) less readability. In the end I quickly abandonded my experiments and returned to no type hints.
I also find it kind of hilarious that type checking isn't built into the standard python interpreter, but you need a separate tool instead. It took me a couple of wasted hours until I discovered that my carefully type-hinted code was not actually type-checked, and after discovering that I was baffled that I can't just do something like "python --type-checked bla.py".
TL;DR: for many use cases, Python's duck typing is a feature, not a bug :)
Perhaps it might not make sense to write type hints for your own prototyping code, but the fact that many libraries and stdlib functions are annotated certainly improves my velocity.
Yes! I find this with TypeScript and JavaScript too. Even if I’m just writing a quick script in JS, the fact that most of the libraries I’m using have TS definitions is really useful.
> I also find it kind of hilarious that type checking isn't built into the standard python interpreter, but you need a separate tool instead.
Agreed, typically you don't add new syntax to a language only to silently ignore it. I think the plan may be to add runtime checking to the Python interpreter later.
The reason is that the community decided they needed some form of type annotations, but nobody could agree on which ones or how they should work. So some syntax was added just so the parser wouldn't fall over, but the semantics were left to other projects to "let 100 flowers bloom".
This worked about as predictably as you would expect. If you grabbed a random package from pypi, suddenly your choice in typechecker might complain about its API if it wasn't made using the same typechecker as you, so a separate, "standard" choice in typechecking was made called mypy. But they couldn't break older code not using mypy so it's strictly optional.
> Agreed, typically you don't add new syntax to a language only to silently ignore it.
The only new syntax here is variable and function annotations and it allows you to put anything into the annotation, so it makes sense the compiler would ignore them. Type hints are one possible usage of such annotations but they are not part of the syntax (because the types are just regular Python objects).
The trick in general is to focus on the types of (top-level) functions. This way, it can be super concise and machine-readable API documentation. (In Haskell, it's great how the type is defined above the function, where documentation also goes.)
Regarding the example of the original article, it demonstrates how type hinting doesn't turn an inherently dynamic language like Python or JavaScript into Haskell, where everything is neatly typed. Type-wise, it just does not make much sense to use the operator + for all the things it's used for in Python, hence the example function slow_add does not make sense either.
I admit I have difficulty knowing when I should just use Any and stop trying harder.
My trouble with this approach is that my brain is not very good at type inference, so I don't really understand what's going on just by reading the code. IDEs can help, but it's still a hassle (esp. in contexts where you don't have IDE - github PRs etc.)
slow_add is not simple. It reimplements the Python + operator, which is quite complex, specially if you look at it from a type system perspective. As noted, its implementation is very core to the language and it has several edge cases. That's not usually what you do when you create a function. Rather, you have very specific types that you support. It's only "simple" because adding things together is a basic operation.
Even if you write a function that encapsulates some funky arithmetic. You will probably be using more operations, to the point that anything but numbers will really make sense.
That said, yes, adding types to an API that wasn't implemented with a typing system in mind can be challenging. But I feel like you get a better API at the end of that exercise.
This is exactly what bothered me with this article but I couldn't put it into words:
> That said, yes, adding types to an API that wasn't implemented with a typing system in mind can be challenging.
The title is just straight up clickbait. Type hinting doesn't suck, adding types to an existing project used by users who have accustomed themselves to an untyped system that lets them do whatever sucks. If this were typed as int, int from the get go, the article would be a hell of a lot shorter.
Groovy taught me that opt-in typing always sucks. Either a language is statically typed from it's inception or it's not. Type hinting is like putting up doors with locks around a house that has no walls to begin with.
Is anyone able to summarise how python got to this point? I haven't used it seriously since the tail end of the 2.7 woes but liked it a lot back then. Good native dictionary type and first class closures worked for me. Scattering of unit tests. The type annotation idea always seemed inconsistent with the language to me so I've ignored it.
In particular I'm wondering if this is a consequence of the rumours that python scales badly - someone changes some module far away, runs the massive test suite and it passes, checks in their code, and your code promptly blows up because the interaction wasn't tested.
There also seems to be a current enthusiasm for statically typing everything on hackernews which might be reflective of the wider industry, possibly making python acceptable collateral damage as it was on the wrong side.
That's my conjecture though, would love to hear from someone closer to the game how type hints became such a big deal in the python world.
My understanding is that Python is used by millions of people to write programs measured in tens of lines, and by tens of large companies writing millions of lines.
Many in the first group are happy with dynamic typing. Those in the second group would have been better off with a compiled language but are too invested in Python to switch to something different, so are trying to morph Python itself into something different.
Unfortunately, the way Python’s governance works, all decisions about the future of the language are made by people in the second group. For example, IIRC the Python Steering Council is composed entirely of developers working for large tech companies - no scientists, finance workers etc at all.
My theory is that huge code bases are always more error prone then small code bases. And if a language is controlled by a committee they will destroy it.
> I'm wondering if this is a consequence of the rumours that python scales badly
My (completely uninformed) guess is that people want to statically type all the things not because it improves correctness, but because it makes editor facilities like code completion and jump-to-documentation so much more effective.
At first glance this is a pretty odd take, would you mind elaborating? I wouldn't say Python devs and web devs have any more overlap than web devs and some other random group of devs you could select, so why is it the case here? It's always easy to say that it's [outgroup]'s fault that [ingroup] is going sour, but is it really the case?
I'm coming more and more to the conclusion that if you need typing for Python, you might as well go full throttle and use Java (maybe TS/Deno?), unless you're in a specialized ecosystem like data science and you have no choice.
Typehints are a great way to document code. If the type hints get too complex they can be cumbersome though. For example passing an int or None if the value doesn’ exist
I was expecting the article to get to the end and have him invent an massive type system that allows you to pass any two types as long as your can add them together. Which, of course, is what it did at the beginning.
Readit News
I also find it kind of hilarious that type checking isn't built into the standard python interpreter, but you need a separate tool instead. It took me a couple of wasted hours until I discovered that my carefully type-hinted code was not actually type-checked, and after discovering that I was baffled that I can't just do something like "python --type-checked bla.py".
TL;DR: for many use cases, Python's duck typing is a feature, not a bug :)
Agreed, typically you don't add new syntax to a language only to silently ignore it. I think the plan may be to add runtime checking to the Python interpreter later.
This worked about as predictably as you would expect. If you grabbed a random package from pypi, suddenly your choice in typechecker might complain about its API if it wasn't made using the same typechecker as you, so a separate, "standard" choice in typechecking was made called mypy. But they couldn't break older code not using mypy so it's strictly optional.
The only new syntax here is variable and function annotations and it allows you to put anything into the annotation, so it makes sense the compiler would ignore them. Type hints are one possible usage of such annotations but they are not part of the syntax (because the types are just regular Python objects).
And slow the run time back down several versions.
Regarding the example of the original article, it demonstrates how type hinting doesn't turn an inherently dynamic language like Python or JavaScript into Haskell, where everything is neatly typed. Type-wise, it just does not make much sense to use the operator + for all the things it's used for in Python, hence the example function slow_add does not make sense either.
I admit I have difficulty knowing when I should just use Any and stop trying harder.
Even if you write a function that encapsulates some funky arithmetic. You will probably be using more operations, to the point that anything but numbers will really make sense.
That said, yes, adding types to an API that wasn't implemented with a typing system in mind can be challenging. But I feel like you get a better API at the end of that exercise.
> That said, yes, adding types to an API that wasn't implemented with a typing system in mind can be challenging.
The title is just straight up clickbait. Type hinting doesn't suck, adding types to an existing project used by users who have accustomed themselves to an untyped system that lets them do whatever sucks. If this were typed as int, int from the get go, the article would be a hell of a lot shorter.
In particular I'm wondering if this is a consequence of the rumours that python scales badly - someone changes some module far away, runs the massive test suite and it passes, checks in their code, and your code promptly blows up because the interaction wasn't tested.
There also seems to be a current enthusiasm for statically typing everything on hackernews which might be reflective of the wider industry, possibly making python acceptable collateral damage as it was on the wrong side.
That's my conjecture though, would love to hear from someone closer to the game how type hints became such a big deal in the python world.
Many in the first group are happy with dynamic typing. Those in the second group would have been better off with a compiled language but are too invested in Python to switch to something different, so are trying to morph Python itself into something different.
Unfortunately, the way Python’s governance works, all decisions about the future of the language are made by people in the second group. For example, IIRC the Python Steering Council is composed entirely of developers working for large tech companies - no scientists, finance workers etc at all.
My (completely uninformed) guess is that people want to statically type all the things not because it improves correctness, but because it makes editor facilities like code completion and jump-to-documentation so much more effective.
Python is increasingly trying to cater to the extremely online and loud webdev crowd. Living in an ivory tower is fine if you're inside it.