I'm of two minds. I like most python code to be untyped where types are obvious. But I almost always use them for function signatures, unless they're absurdly trivial. And once I have a collection where it is not a matter of the utmost ease to determine what the contained type is, I add a type hint for that.

Class members, I generally always type. Hmm let me think. That's probably about it.

I extensively use named tuples and dataclasses too which I think also benefit from having as much type info as possible. I think it fills them in nicely given they're already immutable.

My first job - 5 years - was being neck deep in a huge python 2 codebase with dubious historical maintenance and programmer capability track record. I grew to despise enormous List[Dict[Tuple[str, str, str], Tuple[str, str, int]]] except that oopsies! Sometimes that int is a float and sometimes null and sometimes a string and on the last day of the month one of the records will be a custom class that we insert and test for to handle specially.

Also cases where some variable is passed down through multiple call sites without usage and a short name - like "f" - and it's not clear to me if it's a file, an io object, a string holding a filename, or what. I'd like that typed too.

Same here. I used type annotations before static analyzers became popular, and was quite happy with them (though I would not enforce them). They were a great source of documentation. And yes, like any documentation, occasionally they can deviate from reality.

With static analysis they won't deviate anymore. But the price you're paying for this is verbosity, complexity, and constant support of types.

I find Python static analysis incredibly unpythonic.

Disclaimer: what I'm about to say has resulted, in the past, in someone on HN harassing me in a conversation of 30+ nested depth levels, and his line of attack was basically alternating between "you don't understand type hints" and "what is your company optimizing for, anyway?".

So before I say this, let's agree nobody will harass anybody, and we will politely disagree on this.

Ok, disclaimer done. Here's what I got to say:

I find Python type hints unsatisfying because they don't do enough. Existing type checkers that use them have limitations, are difficult to use beyond trivial usage, and fail to detect cases which are trivial for statically typed languages. Because of this, you never feel truly safe or covered because you're using them, so writing type hints seems like wasteful effort that is difficult to justify to skeptical Python developers.

However, simply saying "it's not enforced, it's just documentation" is also unsatisfying to me. Computers should work for us; if they can automate and enforce something, we should let them. This feels like the worst of both worlds: it's unenforced, slowly-drifting documentation (so the language does very little work for you) but it lacks the freeform of other documentation styles, and you must follow a formal syntax. And developers don't like writing it, since it does nothing anyway.

I agree that it's unsatisfying when compared to a statically typed language. There's a time and place for those. But the ability to use it only where it actually adds value--like at an API boundary where you don't know who will be calling your function but you want to help their IDE help them--that's pretty cool.

The problem is justifying type hints to skeptical developers with no experience from either world.

Coming from the statically typed world, I struggled to justify type hints to inexperienced devs who saw all the holes in them, and so they simply refused. I had no authority to enforce anything, and in any case, enforcing by mandate is not ideal.

So I wish type hints were better so that my arguments for them could be more solid.

I've had a lot of luck with:

"ok now type g... wait, why isn't get_foo autocompleting for you? Hold on, lets go add a hint..."

I realize that you're not going to piecemeal your way to satisfying mypy output like this, but I think it plants the seed in a way that prevents the mentor from being the type-cops.

The API is where type hints should absolutely be mandatory for any serious project in my opinion, and my company has adopted this stance for all new code being written.

Even then, I still fully type all of my code because it lets me write fewer tests.

The types that let you write fewer tests are the types that work consistently and are sufficiently enforced by the tooling; sadly, not the kind type hinting that Python has ;)

I think I can do a healthy disagreement without harassment.

> Computers should work for us; if they can automate and enforce something, we should let them

I agree. But in my experience type hints are often treated as a goal, not as a low cost solution. "We're not going to compromise on type safety". Same happens in TypeScript ecosystem.

As you correctly mentioned, Python type hints are somewhat limited. So naturally what happens next is people change the way they write code to work around those limitations. Readability and velocity (major things Python is praised for) gets sacrificed for the sake of "type safety".

The promise was for tooling to correct my mistakes. But more often than not I felt that I have to correct tooling mistakes.

Before mypy became popular, I often used type annotations because I wanted to. I didn't use them everywhere, I wouldn't enforce them in code reviews, I would never use deeply nested types (those are just unreadable) or generics. I was able to extract value from type hints, they gave me 80% of value for 20% of effort. Static analysis feels like it tries to get another 10% of value for 90% of cost. It's not a good deal anymore.

Thanks for the reply. I think we actually agree on this, only coming from different sides.

As an aside, if this is the disclaimer you give out before saying your opinion on Python type hints... how do you handle dishing out your political views or other more serious matters?

I expect opposition when discussing political topics.

I wrote this disclaimer because I was surprised to find harassment for such a harmless topic as Python's type hinting. I'm surprised dang never stepped in. The flamewar went for a surreal nesting depth, and you know what goes on at that level -- nobody cares what the initial disagreement was, we were arguing about the meaning of the word "is" at that point.

I'm typing my code very often for static analysers.