I think I've always used Python type hints, but that was partially because early versions of Discord.py relied on them (maybe it still does). But it was also because I like to be able to mentally verify my code's correctness before running it, and waiting for runtime errors is comparatively a huge waste of time (in my opinion).
Type hints are much easier to use nowadays than they were a few years ago, because the agentic tools like Claude Code are very good at converting an existing codebase to using type hints.
I enforce strong types on all Python code I’m responsible for - and make sure others don’t play fast and loose with dict[str, Any] when they could use a well defined type.
Doing otherwise is just asking for prod incidents.
Typescript turned me into a believer but my gosh do python typings feel clumsy and quickly busy up files. I get why, and it’s not exactly realistic, but I wish a lot of it didn’t require an import.
Whatever the solution is, it doesn’t include giving up on Python typings.
Type hints in dynamic languages are great, but I wish they came with deeper integration into the language runtime for validation and for optimizer setup.
If I have a function that takes an int, and I write down the requirement, why should a JIT have to learn independently of what I wrote down that the input is an int?
I get that it's this way because of how these languages evolved, but it doesn't have to stay this way.
The biggest reason I use typehints is that VSCode's intellisense relies on them - and I know I've missed one when typing a dot doesn't give me the method I'm expecting.
I really love Python for it's expedience, but type hints still feel like they don't belong in the language. They don't seem to come with the benefits of optimisation that you get with static typed languages. As someone who uses C and Julia (and wishes they had time for Rust), introducing solid typing yields better end results at a minimum, or is a requirement at the other end of the scale.
The extra typing clarification in python makes the code harder to read. I liked python because it was easy to do something quickly and without that cognitive overhead. Type hints, and they feel like they're just hints, don't yield enough of a benefit for me to really embrace them yet.
Perhaps that's just because I don't use advanced features of IDEs. But then I am getting old :P
EDIT: also, this massively depends on what you're doing with the language! I don't have huge customer workloads to consider any longer..!
> They don't seem to come with the benefits of optimisation that you get with static typed languages
They don't. And cannot, for compatibility reasons. Aside from setting some dunders on certain objects (which are entirely irrelevant unless you're doing some crazy metaprogramming thing), type annotations have no effect on the code at runtime. The Python runtime will happily bytecode-compile and execute code with incorrect type annotations, and a type-checking tool really can't do anything to prevent that.
> The extra typing clarification in python makes the code harder to read
It’s funny, because for me is quite the opposite: I find myself reading Python more easily when there are type annotations.
One caveat might be: for that to happen, I need to know that type checking is also in place, or else my brain dismissed annotations in that they could just be noise.
I guess this is why in Julia or Rust or C you have this stronger feeling that types are looking after you.
Remembering project where type hints would have been helpful to grok the code I do now mostly like them. They are useful when you come back after days or weeks and try to remember what does this function produce and what does this one actually take in.
And Python always was rather strongly typed, so you anyway had to consider the types. Now you get notes. Which often do help.
> The extra typing clarification in python makes the code harder to read.
It depends what you mean by "read". If you literally mean you're doing a weird Python poetry night then sure they're sort of "extra stuff" that gets in the way of your reading of `fib`.
But most people think of "reading code" and reading and understanding code, and in that case they definitely make it easier.
Because they follow any corporate initiative that gives them something to do, even if the type hints are the most unreadable and hackish form of typing in existence.
This is a naive realization. When type checking is used to the maximum extent they become as just as important as unit testing. It is an actual safety contribution to the code.
Many old school python developers don't realize how important typing actually is. It's not just documentation. It can actually roughly reduce dev time by 50% and increase safety by roughly 2x.
This resonates with me this so much. I feel like half the comments in this thread are missing the value typing, but maybe they've never had the misfortune of working with hundreds of other developers on a project with no defined contracts on aggregates / value objects outside of code comments and wishful thinking.
I've worked on large python codebases for large companies for the last ~6 years of my career; types have been the single biggest boon to developer productivity and error reduction on these codebases.
Just having to THINK about types eliminates so many opportunities for errors, and if your type is too complex to express it's _usually_ a code smell; most often these situations can be re-written in a more sane albeit slightly verbose fashion, rather than using the more "custom" typing features.
No one gets points for writing "magical" code in large organizations, and typing makes sure of this. There's absolutely nothing wrong with writing "boring" python.
Could we have accomplished this by simply having used a different language from the beginning? Absolutely, but often times that's not a option for a company with a mature stack.
TL;DR -- Typing in python is an exception tool to scale your engineering organization on a code-base.
I love typing in Python. I learnt programming with C++ and OOPs. It was freeing when I took up Python to note care about types, but I have come to enjoy types as I got older.
But, boy have we gone overboard with this now? The modern libraries seem to be creating types for the sake of them. I am drowning in nested types that seem to never reach native types. The pain is code examples of the libraries don’t even show them.
Like copy paste an OpenAI example and see if LSP is happy for example. Now I have gotten in this situation where I am mentally avoiding type errors of some libraries and edging into wishing Pydantic et al never happened.
> But, boy have we gone overboard with this now? The modern libraries seem to be creating types for the sake of them. I am drowning in nested types that seem to never reach native types.
Thought you were talking about TypeScript for a moment there.
I learned C++ before learning python as well and python felt like a breath of fresh air.
At first I thought it was because of the lack of types. But in actuality the lack of types was a detriment for python. It was an illusion. The reason why python felt so much better was because it had clear error messages and a clear path to find errors and bugs.
In C++ memory leaks and seg faults are always hidden from view so EVEN though C++ is statically typed, it's actually practically less safe then python and much more harder to debug.
The whole python and ruby thing exploding in popularity back in the day was a trick. It was an illusion. We didn't like it more because of the lack of typing. These languages were embraced because they weren't C or C++.
It took a decade for people to realize this with type hints and typescript. This was a huge technical debate and now all those people were against types are proven utterly wrong.
In addition to what others have mentioned, it also just makes it easier to come back later to a code base and make changes, especially refactoring. In many cases you don't even really have to add many type hints to get benefits from it, since many popular libraries are more-or-less already well-typed. It can also substitute for many kinds of unit tests that you would end up writing even 5 years ago. If you're an infrastructure engineer or data scientist that's usually just writing a lot of glue code, then it greatly helps speed up your output (I've found)
Without typing it is literally 100x harder to refactor your code, types are like a contract which if are maintained after the refactor gives you confidence. Over time it leads to faster development
I hate typing in Python. I spend a good chunk of my day fighting the type checker and adding meaningless assertions, casts, and new types all to satisfy what feels like an obsessive compulsive nitpicker. "Type partially unknown" haunts my dreams.
Duck typing is one of the best things about Python. It provides a developer experience second to none. Need to iterate over a collection of things? Great! Just do it! As long as it is an iterable (defined by methods, not by type) you can use it anywhere you want to. Want to create a data object that maps any hashable type to just about anything else? Dict has you covered! Put anything you want in there and don't worry about it.
If we ended up with a largely bug free production system then it might be worth it, but, just like other truly strongly typed languages, that doesn't happen, so I've sacrificed my developer experience for an unfulfilled promise.
If I wanted to use a strongly typed language I would, I don't, and the creeping infection of type enforcement into production codebases makes it hard to use the language I love professionally.
Couldn't agree more! I've been using Python for almost 20 years, my whole career is built on it, and I never missed typing.
Code with type hints is so verbose and unpythonic, making it much harder to read. Quite an annoying evolution.
> Duck typing is one of the best things about Python.
And duck typing with the expected contract made explicit and subject to static verification (and IDE hinting, etc.) is one of the best things about Python typing.
> If we ended up with a largely bug free production system then it might be worth it, but, just like other truly strongly typed languages, that doesn't happen
I find I end up at any given level of bug freeness with less effort and time with Python-with-types than Python-without-types (but I also like that typing being optional means that its very easy to toss out exploratory code before settling on how something new should work.)
Type hints in python are just that, hints. Use them to help with clarity but enforcing them and requiring them everywhere generally leads to the worst of all worlds. Lots of boilerplate, less readable code and throwing away many of the features that make python powerful. Use the best language for the job and use the right language features at the right time. I see too many black or white arguments in the developer community, there is a middle ground and the best code is almost always written there.
> Lots of boilerplate, less readable code and throwing away many of the features that make python powerful.
IMO, that complaint almost always goes with overuse of concrete types when abstract (Protocol/ABC) types are more accurate to the function of the code.
There was a time that that was a limitation in Python typing, but that that hasn’t been true for almost as long as Python typing had been available at all before it stopped being true.
It's the other way around, IMO: people who think the language should at least have type hints are now more willing to use it, now that there's better tooling for checking those hints.
I really think that Rust has one of the best designed/inspired type systems.
If I had to rewrite a Python project, I would consider Rust or another statically typed language before choosing to continue in a dynamic language with types bolted on. I hope the situation improves for dynamic languages with optional types, but it still feels weird and bolted onto the language because it is.
Has anyone had good luck with auto-annotation of types of existing codebases? Either via LLM or via various runtime hooks? I work in a codebase that started off in Python 2 and isn't annotated with types in the majority of places, and I feel the pain every time I have to wonder what exactly the arguments to a method is.
This is why I think Julia will win in the long run. It has an amazing type system, simple yet powerful. In particular, abstract types are much easier to define and use than abstract classes in Python.
102 comments
[ 3.3 ms ] story [ 86.8 ms ] threadDoing otherwise is just asking for prod incidents.
Whatever the solution is, it doesn’t include giving up on Python typings.
If I have a function that takes an int, and I write down the requirement, why should a JIT have to learn independently of what I wrote down that the input is an int?
I get that it's this way because of how these languages evolved, but it doesn't have to stay this way.
The extra typing clarification in python makes the code harder to read. I liked python because it was easy to do something quickly and without that cognitive overhead. Type hints, and they feel like they're just hints, don't yield enough of a benefit for me to really embrace them yet.
Perhaps that's just because I don't use advanced features of IDEs. But then I am getting old :P
EDIT: also, this massively depends on what you're doing with the language! I don't have huge customer workloads to consider any longer..!
They don't. And cannot, for compatibility reasons. Aside from setting some dunders on certain objects (which are entirely irrelevant unless you're doing some crazy metaprogramming thing), type annotations have no effect on the code at runtime. The Python runtime will happily bytecode-compile and execute code with incorrect type annotations, and a type-checking tool really can't do anything to prevent that.
It’s funny, because for me is quite the opposite: I find myself reading Python more easily when there are type annotations.
One caveat might be: for that to happen, I need to know that type checking is also in place, or else my brain dismissed annotations in that they could just be noise.
I guess this is why in Julia or Rust or C you have this stronger feeling that types are looking after you.
And Python always was rather strongly typed, so you anyway had to consider the types. Now you get notes. Which often do help.
It depends what you mean by "read". If you literally mean you're doing a weird Python poetry night then sure they're sort of "extra stuff" that gets in the way of your reading of `fib`.
But most people think of "reading code" and reading and understanding code, and in that case they definitely make it easier.
In my experience I have seen far too much Python code like
`def func(data, args, *kwargs)`
with no documentation and I have no clue wtf it's doing. Now I am basically all in on type hints (except cases where it's impossible like pandas).
Turns out they just didn't know any better?
Python has a great experience for a bunch of tasks and with typing you get the developer experience and reliability as well.
But it's really valuable documentation! Knowing what types are expected and returned just by looking at a function signature is super useful.
Many old school python developers don't realize how important typing actually is. It's not just documentation. It can actually roughly reduce dev time by 50% and increase safety by roughly 2x.
> But it's really valuable documentation! Knowing what types are expected and returned just by looking at a function signature is super useful.
So ... you didn't have this realisation prior to using Python type hints? Not from any other language you used prior to Python?
I've worked on large python codebases for large companies for the last ~6 years of my career; types have been the single biggest boon to developer productivity and error reduction on these codebases.
Just having to THINK about types eliminates so many opportunities for errors, and if your type is too complex to express it's _usually_ a code smell; most often these situations can be re-written in a more sane albeit slightly verbose fashion, rather than using the more "custom" typing features.
No one gets points for writing "magical" code in large organizations, and typing makes sure of this. There's absolutely nothing wrong with writing "boring" python.
Could we have accomplished this by simply having used a different language from the beginning? Absolutely, but often times that's not a option for a company with a mature stack.
TL;DR -- Typing in python is an exception tool to scale your engineering organization on a code-base.
But, boy have we gone overboard with this now? The modern libraries seem to be creating types for the sake of them. I am drowning in nested types that seem to never reach native types. The pain is code examples of the libraries don’t even show them.
Like copy paste an OpenAI example and see if LSP is happy for example. Now I have gotten in this situation where I am mentally avoiding type errors of some libraries and edging into wishing Pydantic et al never happened.
Thought you were talking about TypeScript for a moment there.
At first I thought it was because of the lack of types. But in actuality the lack of types was a detriment for python. It was an illusion. The reason why python felt so much better was because it had clear error messages and a clear path to find errors and bugs.
In C++ memory leaks and seg faults are always hidden from view so EVEN though C++ is statically typed, it's actually practically less safe then python and much more harder to debug.
The whole python and ruby thing exploding in popularity back in the day was a trick. It was an illusion. We didn't like it more because of the lack of typing. These languages were embraced because they weren't C or C++.
It took a decade for people to realize this with type hints and typescript. This was a huge technical debate and now all those people were against types are proven utterly wrong.
Without typing it is literally 100x harder to refactor your code, types are like a contract which if are maintained after the refactor gives you confidence. Over time it leads to faster development
Duck typing is one of the best things about Python. It provides a developer experience second to none. Need to iterate over a collection of things? Great! Just do it! As long as it is an iterable (defined by methods, not by type) you can use it anywhere you want to. Want to create a data object that maps any hashable type to just about anything else? Dict has you covered! Put anything you want in there and don't worry about it.
If we ended up with a largely bug free production system then it might be worth it, but, just like other truly strongly typed languages, that doesn't happen, so I've sacrificed my developer experience for an unfulfilled promise.
If I wanted to use a strongly typed language I would, I don't, and the creeping infection of type enforcement into production codebases makes it hard to use the language I love professionally.
And duck typing with the expected contract made explicit and subject to static verification (and IDE hinting, etc.) is one of the best things about Python typing.
> If we ended up with a largely bug free production system then it might be worth it, but, just like other truly strongly typed languages, that doesn't happen
I find I end up at any given level of bug freeness with less effort and time with Python-with-types than Python-without-types (but I also like that typing being optional means that its very easy to toss out exploratory code before settling on how something new should work.)
Sometimes you don't have a choice though, and other people have picked Python despite it rarely being the best language for any job.
In that case it's nice to be able to use static type hints and benefit from improved readability, productivity and reliability.
IMO, that complaint almost always goes with overuse of concrete types when abstract (Protocol/ABC) types are more accurate to the function of the code.
There was a time that that was a limitation in Python typing, but that that hasn’t been true for almost as long as Python typing had been available at all before it stopped being true.
If I had to rewrite a Python project, I would consider Rust or another statically typed language before choosing to continue in a dynamic language with types bolted on. I hope the situation improves for dynamic languages with optional types, but it still feels weird and bolted onto the language because it is.
Also should check out ty by astral, it is pretty fast and does a good job at typechecking.
https://docs.astral.sh/ty/editors/