Tom Ritchford
2 min readNov 7, 2023


I'm enjoying your article, but this sentence is a bit week. Oh, it's not that it takes much time to, ah, type the typing, but it takes you time to think up the typing.

Most of the time that is very little but occasionally coming up with the correct type can be surprisingly hard.

Also, if you are adding types to legacy code, you have the problem of what I call "color changing variables" - variables (which might be members) that have different types at different points in the program.

(The typical example is that the "input" into your data structure can be a string, None meaning "use default", or the actual class, but at some point you convert the None or string into an actual class.)

I came to Python from Java and C++ in 2004, and I didn't miss strong typing as much as I expected.

Then I went from a completely untyped Python project to one where I was tasked with adding types to it.

And I'm not going back! It takes very roughly 10% more time to write fully-typed code but the savings in reliability and readability more than compensate for this.

My current open-source project is fairly tricky because it's real-time and has a lot of user settable flags.

Using typing from the very beginning (I'm using mypy --strict which is extremely restrictive) slowed me down initially but now has been allowing me to make progress much faster than I would have expected at this stage, and is also catching a lot more errors before I run the code, particularly errors that aren't on the Happy Path, though I am the sort of person who unit tests my exception handling quite thoroughly...

Blah blah, thanks for an absorbing article, accept claps!