> 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.

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.

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.

> for more complex data structures (think a json response from an api), dict (or typing.Dict) work fine

One of the reason I use typing is IDE completion and error highlighting. For that purpose - I make sure to annotate even the obvious primitive types and for API responses, I find that defining a Pydantic model works very well.

Considering that most AI add-ons type hint code reasonably well, there no real reason not to, just for readability.

It takes a few seconds to prompt and then check it.

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