1a) Module/class collision. I like to use the primary class in a file as the name of the file. However this can lead to namespace collisions between the module name and the class name. Also it means that I'm going to be stuck with the odious and wasteful syntax foo.foo everywhere, or forced to use "from foo import *".
The normal convention is to use a initial uppercase letter when defining a class and using all lowercase letters for naming a file/ module.
For example you might have a file called foo.py with the following: class Foo: passNow no namespace collision will result when you import the foo file/ module.
1b) The Pythonic way seems to be to put more stuff in one file, but I believe this is categorically the wrong thing to do in large projects. The moment you have more than one developer along with a revision control system, you're going to want files to contain the smallest practical functional blocks. I feel pretty confident saying that "put more stuff in one file" is the wrong answer, even if it is the Pythonic answer.
Each file is considered a module in python. You usually don't want to throw everything into one module, especially for big projects. Breaking your code down into meaningful modules that can be reused in other modules. There is no general rule to follow here as far as length of a file/module is concerned. Use your judgment here.
-- http://mail.python.org/mailman/listinfo/python-list
