Package organization

[Mike Wyatt]

You read me like a book :)  I just moved from C# a few months ago, and I 
played with C++ for a while before that.

Seriously though, for some of my more complicated subsystems (graphics, 
for example), putting all the classes in one module seems excessive.  
Right now that subsystem has around 10 classes, and may end up with 
about twice that.  I could find a logical split between a few modules, 
but that would defeat the purpose of reducing the level of nesting.  
Having all my code in a single module would make it hard to find the 
code I want to edit quickly.

------------------------------------------------------------------------

Subject:
Re: Package organization
From:
Matt Good <matt.good at gmail.com>
Date:
Sat, 15 Jul 2006 15:57:22 -0700

To:
python-list at python.org


One class per module?  Sounds like you've been programming in Java (or
C#) for too long  :) 

But skipping the package structure for a moment you can simplify your
use of the Timer class by changing your imports:

from engine.timer.timer import Timer
t = Timer()

OR

from engine.timer import timer
t = timer.Timer()

Ok, back to package structure.  In Python putting 1 class per module
basically means you're adding an extra level of nesting beyond the
equivalent structure in languages like Java and C# that require you to
create a new file per-class.

In Java defining "engine/timer/Timer.java" you'd get an
"engine.timer.Timer" class.
As you saw in Python defining Timer in "engine/timer/timer.py" the
class is now "engine.timer.timer.Timer".

Dropping that extra level by combining the classes in engine.timer into
a single module will simplify things.

-- Matt Good



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20060725/c7560954/attachment.html>