That's simply not true. There is a compilation step in python that is completely distinct from the runtime (i.e. when the bytecode files are compiled). There's nothing special about python that prevents static compile time analysis from happening.
Oh, and to address your other point: the line between compiled and interpreted languages has been blurry since day one, and it's only getting blurrier. No modern, highly-used interpreted language gets by these days without compilation to bytecode. Rather than "compilation vs. interpretation", the battle should be "interpretation vs. native execution", which is more meaningful, but the line there is actually still pretty blurry (see JIT compilation, which straddles that line).
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.
