Package organization

[Matt Good]

Mike Wyatt wrote:
> I've been playing around with Python for a few months now, and I just
> recently started looking at packages to organize my growing project.  So
> far, I've been organizing my application into one class per module.
> This has been working pretty well.  For example, I simply "import
> timer", then use "t = timer.Timer()" to allocate a new Timer object, .
> Unfortunately, this is yielding some pretty odd syntax when I use
> packages.  Here is a sample of my package structure:
>
> /engine
>     /graphics
>     /input
>     /world
>     /timer
>         timer.py       # contains Timer class
> main.py
>
> Let's say I want to create a Timer object in main.py.  I would need to
> do something like this:
>
> import engine.timer.timer.Timer
> t = engine.timer.timer.Timer()
>
> Maybe I shouldn't have a module and package with the same name, but it
> seems the most logical design.  Unfortunately, the code is a bit ugly
> with "timer" included in the import three times.
>
> Is there a better way to do this?  How do you guys organize your
> packages and modules?

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