I come from a background where I normally create one file per class. I organize common classes under directories as well. This practice is intuitive to me and it has been proven to be effective in C++, PHP, JavaSript, etc. 
I am having trouble bringing this metaphor into Python: files are not just files anymore, but they are formal modules. It doesn't seem right to just have one class in a module --- most classes are useless by themselves. If I have a automobile.py and an Automobile class, it seems silly to always reference it as automobile.Automobile as well.
But, at the same time, it doesn't seem right to throw a ton of code into one file and call it a day. Obviously, a very complex application should have more than 5 files.
What is the correct---or pythonic---way? (Or if there is no correct way, what is your preferred way and why?) How much code should I be throwing in a Python module?
If you are coming from a c++ point of view, you could view python modules akin to a .so or .dll. Yeah they look like source files, because python is scripted, but they are actually loadable libraries of specific functionality. 
Another metaphor that may help is you might look python modules as namespaces.
The Pythonic way of organizing modules and packages