«

Hi.

I found a lot of documentation about how to code in Python, but not
much about how you organize your code in various modules / packages ...
As I am not yet used to python, this puzzle me a bit.

So, can anyone explain how one should organize and store its code ? the
uses of __init__.py files ? Maybe my question is not very clear, but I
hope someone will understand anyway ...

Thomas

Thomas Girod wrote:
> Hi.
>
> I found a lot of documentation about how to code in Python, but not
> much about how you organize your code in various modules / packages ...
> As I am not yet used to python, this puzzle me a bit.
>
> So, can anyone explain how one should organize and store its code ? the
> uses of __init__.py files ? Maybe my question is not very clear, but I
> hope someone will understand anyway ...

Well... As a starting point relative to Python specific stuff (use of
__init__.py etc), the Fine Manual is your friend:
http://www.python.org/doc/2.4.2/tut/node8.html

Now for best practices and whatnots, this isn't really specific to
Python. Try to have modules with high cohesion and low coupling, and
it'll be fine. Eventually try to provide a facade class or function for
complex packages (this is a current pattern in the standard lib).

Also, python-is-not-java, so don't feel commited to putting everything
in classes when plain functions would do, and avoid the 1:1 class/file
Java plague !-)

My 2 cents...
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in ''.split('@')])"

bruno at modulix wrote:
> Thomas Girod wrote:
>>
>>I found a lot of documentation about how to code in Python, but not
>>much about how you organize your code in various modules / packages ...
>>As I am not yet used to python, this puzzle me a bit.
>
> Now for best practices and whatnots, this isn't really specific to
> Python. Try to have modules with high cohesion and low coupling, and
> it'll be fine. Eventually try to provide a facade class or function for
> complex packages (this is a current pattern in the standard lib).

Also, be aware of dependencies between packages and make sure they are
acyclic - if a module in package A imports a module in package B, then A
depends on B and B should not be allowed to also depend on A either
directly (module in B imports module in A) or indirectly (module in B
imports module in C which imports module in A).

If you follow this rule your packages will be more testable and
reusable. The alternative tends to devolve into
everything-depends-on-everything-else which makes testing harder and
reuse nearly impossible.

Kent