[Tutor] Module Packages

[Alan Gauld]

> In the one-file format, I have the following classes

If you mean by one-file format that you have one
class per file, can I ask why? If the classes are
related its usually better to keep them together IMHO.

> Now, game makes use of both the Player and the Zombie classes, by
creating
> instances of both. Ideally, I'd like to separate things into
subitems:
>
> /Pyrl
>     /Entity
>         Entity.py
>         Player.py
>         /Monster
>             Zombie.py
>     Game.py

Why separate Monsters from other Entities? And why
separate Entities at all, why not just two modules, one
for the Entities and another for the Game itself.

Presumably you might reuse the Entity module but less
likely to reuse the game?

> First question, then, is this a properly done package structure? I'd
like
> to be able to do the following:
>     plr = Entity.Player()
> But it looks like I'll have to:
>     plr = Entity.Player.Player()

Exactly, its easier to use the module to hold all the class
definitions. Fine grained file structures tend to be used
in things like C++ and Java as a mechanism for controlling
compilation times, but they add a lot of undue complexity
to a project in my experience.

> Is there anyway to avoid the "double-referencing"? Or am I going
about my
> package organization all wrong?

I think you should build your module structure based on
the groups of reuse in your code, not the individual classes.
If a bunch of classes are likely to be reused together put
it in a single module.

Alan G.