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>
--
http://mail.python.org/mailman/listinfo/python-list
