structuring a package?

Bruno Desthuilliers bruno.42.desthuilliers at websiteburo.invalid
Mon Jan 5 14:18:06 CET 2009

Torsten Mohr a écrit :
> Hi,
> i have a question on how to structure a package best, would be great if
> anybody could give me some hint on this:
> Assuming i have a base class GraphicObject and derived from that some
> classes like Square, Circle, ...
> It looks natural to me to write in a code that uses the package:
> import graphic
> import graphic.square
> import
> That way i'd have to structure the code like this:
> graphic/
>   __init__,py  (GraphicObject)
> (Square)
> (Circle)
> Does that make sense like this?
> Are there better ways to structure things in Python?

<disclaimer content="just-my-2-cents-really">

Well... Unless your Square and Circle classes are monster classes, or 
you have many many GraphicObject subclasses - that is, unless you need 
to do so for source-file size management -, there's not much reason to 
use a Java-like "one class per file" scheme[1], and it's not the common 
way to organize Python code.

Now if you do have (or just really want - well, it's your code, isn't it 
?-)) to use one-class-per-file, you may be better moving the base 
GraphicObject class in a module. This would be easier to 
understand IMHO, and should make internal imports easier to manage.

[1] A package can act as a facade for submodules/subpackages (using the to expose submodules/subpackages at the top level), so it's 
not a problem to refactor a single module into a package...

> One thing that bothers me is that when i write in something like
> "import graphic", then i can't have the test code for the Circle within
>, at least it looks to me like this.

Depends on how you write your test code, but as far as I'm concerned, I 
prefer to separate source from tests (and use a unittesting framework).


More information about the Python-list mailing list