> After the code has stabilized I can probably go back to write type hints [...] but I'm not sure that this would provide very much value.
I think most developers who revisit their projects 6+ months later would disagree with the second part of this statement.
My typical flow for "quick scripts" is:
on first pass I'll add basic type hints (typing ":str" after a func param takes .2 seconds)
for more complex data structures (think a json response from an api), dict (or typing.Dict) work fine
if you want a Python project to be maintainable, type hints are a requirement imho.
This is my approach too. A kind of "relaxed" typing I often call it. Just knowing what a function expects and returns helps a lot, what each element of a tuple is, or what a list contains. Before type hints, I used to not enjoy Python at all, but these days I find it fun. The few times I spend time pondering about how to type things are greatly outweighed by the time saved of not having to research what type a particular variable is.
That’s basically my approach and attitude, too. I was skeptical at first but I’d never go back to undecorated code. Paired with a decent language server, it’s soooo much easier writing correct code now.
And when I inherit a code base with no type hints asking an LLM to have a go at adding type hints also takes no time at all