Structuring larger applications - ideas

[Dave Brueck]

iv at lantic.net wrote:
> I'm busy with a large application and feel it would eas my work if I
> can specify dependencies on the granularity of packages, rather than
> modules and classes.  Eg:
> 
> - By convention I do the one class per file thing.  SO in python this
> means one class per module - naming classes after their modules. (this
> helps with version control, and several other little irritations, for
> example)
> - I'd like to specify once for a _package_ that it depends upon another
> _package_.
> - The following should then also be true for a module A in package X
> (which depends upon package Y):
>     1) X should be available in the namespaces of module A (in fact for
> all modules in X)
>     2) X.B should refer to X.B.B  (I name classes after their modules).
> 
> (2) Can be done easily by, eg putting the following in X.__init__.py:
>    from B import B
> 
> What's the feeling in this group about the idea & plans to get closer
> to accimplishing it?

My two cents: one of the advantages of a language like Python is that the 
project reaches an unmanageable size more slowly than in many other languages. 
As such, be wary of "importing" conventions you have used in other languages. 
Many will apply, some will not.

IMO, the one-class-per-module is a convention that in and of itself doesn't add 
much value (it drove me crazy in Java), and only accelerates your project 
towards being tough to manage - you don't want to artificially introduce 
complexity. If two classes are inherently tied together and closely related, is 
there an advantage to forcing them to live in separate files? The costs of doing 
so include manually tracking a relationship that would normally be implied and 
obvious, keeping file versions in synch (seems like this makes version control 
harder), and some extra code to bring them into each others' namespaces.

Much like a class encapsulates many details and pieces of functionality into a 
larger, more powerful building block, a module often does the same thing on a 
larger scale (and a package on an even larger one). So if it makes sense in a 
few cases to restrict yourself to a single class per module, go for it, but I 
don't see the value in adopting it as a convention (maybe I'm missing something?).

As for inter-package dependencies, what problem are you trying to solve? If you 
are trying to track dependencies for documentation purposes, you could just 
write a script to walk the source tree and detect the dependencies - it is 
information contained in the code itself, so rather than tracking it manually, 
you could just "ask" it. If you are trying to organize the overall structure of 
the project, then the consumer of that info is likely to be a person, so a piece 
  of paper, a whiteboard, or a big fat docstring might be a better suited home 
for it.

-Dave