structuring a package?

[Bruno Desthuilliers]

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 graphic.circle
> 
> That way i'd have to structure the code like this:
> 
> graphic/
>   __init__,py  (GraphicObject)
>   square.py (Square)
>   circle.py (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 base.py 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 
__init__.py 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 circly.py something like
> "import graphic", then i can't have the test code for the Circle within
> circle.py, 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).

</disclaimer>