Seconded. Even though i write python code, i am still thinking of types. Infact, it's one of my gripes with the language. There are some tired mental states, when i don't think/forget to think about types, but just write and call functions. It's at those times that i find having to go back and read the original function for a type or having to go to REPL for testing the type painful. I would be happy to have a compiler tell me what type is expected instead. I guess more experience will lead me to infer this from the actual error message itself.(ex: Nonetype has no function iter)

You should strive to not rely on type-checking, and trust and rely more on duck-typing. If at some point you need to ensure something is not None, test it and act accordingly in the alternate case. If something absolutely must not be None (or must have a specific method), ever, use assert() so that things blow up upfront where you can infer (or even read) the reason, and not deeper in the code where the actual error message, as you mention, has to be parsed according to the whole call stack to make sense of it.

Sometimes you may need to type-dispatch when you want to do smart functions. A typical example is a function that takes a sequence/iterable/generator of strings or a string. Since a string is iterable in python, you have no choice but to check for BaseString.

Duck typing requires more mental effort to track the variable types. And in python some type errors are detected only in runtime, like when you call a function with a wrong parameter count.