views:

813

answers:

2

I'm getting started with Python (it's high time I give it a shot), and I'm looking for some best practices.

My first project is a queue which runs command-line experiments in multiple threads. I'm starting to get a very long main.py file, and I'd like to break it up. In general, I'm looking for: How do python programmers organize multiple source files? Is there a particular structure that works for you?

My specific questions include:

  1. Should each class be in a separate file?
  2. How should I organize unit tests relative to source code?
  3. Where should I put doc comments, specifically those for command-line operation?
  4. If I use multiple directories, how do I import classes between them?

I can probably draw some of my own conclusions here by trial and error, but I'd rather start from something good.

+13  A: 

I found this article super-helpful while addressing the same problem so hopefully it helps you:

http://infinitemonkeycorps.net/docs/pph/

Eric Wendelin
That is _exactly_ the resource I was looking for!
Andres Jaan Tack
A: 

The way you should organise your code and tests is exactly the same you would for any OO language.

Answers from the way I do it. It may not be right but works for me

  1. Depends on how your functionality is split. For my main python app I have 1 file with classes for the entry points and then packages of different bits of functionality
  2. I use PyDev for eclipse and organise it like I would for Java.
>  Workspace
>     |
>     |-Src
>     |   |-Package1
>     |   |-Package2
>     |   |-main.py
>     |-Test
>         |-TestPackage1
>         |-TestPackage2
  1. Use DocString everywhere to keep track of everything
  2. After making sure that the relevant init.py files are in the folders. its just a simple case of from module import class
AutomatedTester
One caveat, though: java takes kind of a dictatorial relationship with packages, files and classes. Sometimes I end up with way more source files than I would really want. The conventions of some organizations -- e.g. - avoid (nested) inner classes or "helper" classes lower in the file -- make this worse, beyond the compiler's requirements. Keep it orderly, and a hierarchy is useful, but try to avoid make-work.
Roboprog