Project structure - Best practices

[Martin P. Hellwig]

Aaron Watters wrote:
> On Nov 30, 11:55 am, "Filip Gruszczyński" <grusz... at gmail.com> wrote:
>>> http://jcalderone.livejournal.com/39794.html
>> That's exactly what I have read before posting here ;-)
>>
>> --
>> Filip Gruszczyński
> 
> I too would like to see a meatier discussion of best practices
> for python packagizing.  I particularly object to jcalderone's
> suggestion that all tests should be within the package.  Often my
> test cases are 100 times the size of the code, if you include
> sample data -- it doesn't make sense to install it, I think.
<cut>
I agree on that. But I like to add a couple of my thoughts :-)
In my opinion the structuring of your project depends very much on what 
the project is itself. If it is a more a library sort of thing then I 
tend to keep it as small and simple as possible, with the main objective 
to be simple to understand when interfacing with it. I usually structure 
the package like how I think somebody else would expect it to be.

When I am doing an application type of code for myself, I usually end up 
organizing my program the way it is the easiest to maintain, if 
necessary in this case I would sacrifice small and simple over 
robustness and maintainability.

When I am starting a project which is either a payed contract job or I 
anticipate other participants, I orientate my project more around 
documentation and management, I have written an article in the past 
about that (generally written it was still more aimed to the client I 
was working at that moment). If anybody is interested you can get it 
here: 
http://dcuktec.googlecode.com/svn/trunk/documentation/best_practises/DITDD/deliverables/DITDD.pdf

ymmv