Project organization and import

[Nicholas Parsons]

> 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:
   pass

Now 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20070304/b202e5ef/attachment.html>