iv@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