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?
In a mid-sized project, I found myself with several sets of closely related classes.  Several of those sets are now grouped into files; for example, the low-level network classes are all in a single network module.  However, a few of the largest classes have been split out into their own file.
Perhaps the best way to start down that path from a one-class-per-file history is to take the classes that you would normally place in the same directory, and instead keep them in the same file.  If that file starts looking too large, split it.
The Pythonic way of organizing modules and packages