I understand your point. There is a step that compiles python source to bytecode, and it does take place before the bytecode is executed. I just think this is a somewhat pedantic observation. A large part of the value of the language lies in the immediacy of its "interpreted" nature (I'll put that in quotes from now on, thanks to you :)). You run the script and it either fails or executes. In the version of python I use on Ubuntu scripts aren't compiled to bytecode for the first time until they are imported, so other code in the project has likely already run before the compiler would have a chance to review the use of types in the imported module. There isn't a project-wide process of compiling all the files and making sure everything is used correctly before any code executes. Maybe it could be made to work that way, but wouldn't that alter the language and the way it is used? In the end I come back to: is AttributeError really not descriptive enough? You can have the last word here.
Okay. AttributeError is good enough, except when it's not. Python is designed in such a way that makes you actively seek out AttributeErrors, rather than having them diagnosed at compile-time. If that works for you, then that's great, but it doesn't always work. Whether it's in the main branch of CPython, or some sort of experimental fork, or some completely distinct static analysis tool, Pythonistas should support efforts to add (potentially optional) increased static checking to the Python interpreter, because it's a good thing.
Will it fit in with the current Python ecosystem? Will it have to change the way the language is used? Maybe, but that doesn't mean we shouldn't experiment with static analysis. We're hackers, after all, and this is something that probably deserves to be hacked on.
