Completely disagree. The Python community has very rapidly adapted mypy because of widespread recognition that yes, type information is extremely helpful for any code bases larger than a few files and/or worked on by more than a few developers. Every major Python library I can think of now has mypy stubs available. If you're going to dismiss them as "not Pythonic" you may as well dismiss anything other than Python 2.7 as "not Pythonic".
Like, even if you think that type hints have ugly syntax, prior to them vast most projects just didn't bother with documenting the shape of data, so you had to read source code, guess and experiment. Unless you just don't care about knowing what you're specifically working with (which strikes me as living on the edge), how is it not an ergonomics gain?
My experience with Python is that it slows development speed to a crawl due to dynamic typing. It’s maybe faster to write the first 1000 lines. But after that it becomes slower and more painful. At least in my experience.
Okay, this myth that Pythonic == loosey-goosey duck-type-everything slinging dicts and strings nothing static cause that's too slow, really needs to die.
Pythonic is all about pragmatism and parsimony. If that means not typing anything cause it's a 50 line script, do that. If it means the most efficient way for large dev teams to communicate on sprawling code bases is to use rich types, then do that.
Personally, I use types even in the short scripts, because then I can offload keeping track of what type everything is, instead of having to remember yet another user_dict with whatever keys the producer felt like using at the time. It makes autocomplete faster and I'm less mentally fatigued. Less mental fatigue == more pythonic.
def create_user(user):
other_function(user)
Onboarding into a huge, untyped codebase is brutal