Structuring larger applications - ideas

[iv]

Hello,

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?

-i

[Dave Brueck]

[e-mail] 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

[Iwan Vosloo]

I know my foreign (to python) one class per module idea is what makes
life more difficult for me here. And there is an argument to be made
out that it is a stupid remnant I stick to from having used it in other
programming languages (do I have to admit C++ in my background?) Two
small examples of where it it useful for me: my development
environment is run by make to a large extent. Many standard UNIX tools
have the intelligence to deal with filenames, and if you know a file
corresponds to a class, you have a lot more info available in your
makefile. Also, if I use my version control software (currently gnu
arch) to see what's changed, for example, I get a list of changes files
which again gives me more info because I know a file corresponds to a
class.
So, I can do a number of such small things using that convention that
works well with standard old UNIX tools. And I find that valuable.

As for the dependencies- I'm trying to keep the specification of them
simple. From a design point of view, it makes sense to me to only
specify ONCE that largeish-collection-of-classes-A depends on
largeish-collection-of-classes-B. As another simple small example: say
I change the name of large-collection-of-classes-B - this way I only
need to do it once, else I need to grep and sed all over in order to do
it.

It just feels cleaner and easier.

I know essentially, if you stick to having many classes in a python
module, you have what I referred to in the previous paragraph, because
you can stick to importing other modules at the beginning of a module
and so have them and their contens available in the entire file.

Still, I'm investigating whether I can bend the ever-so-flexible python
to work well with my admittedly somewhat strange requirement. And, off
course, I'd like to hear what others think.

-i

[Iwan Vosloo]

I know my foreign (to python) one class per module idea is what makes
life more difficult for me here. And there is an argument to be made
out that it is a stupid remnant I stick to from having used it in other
programming languages (do I have to admit C++ in my background?) Two
small examples of where it it useful for me: my development
environment is run by make to a large extent. Many standard UNIX tools
have the intelligence to deal with filenames, and if you know a file
corresponds to a class, you have a lot more info available in your
makefile. Also, if I use my version control software (currently gnu
arch) to see what's changed, for example, I get a list of changes files
which again gives me more info because I know a file corresponds to a
class.
So, I can do a number of such small things using that convention that
works well with standard old UNIX tools. And I find that valuable.

As for the dependencies- I'm trying to keep the specification of them
simple. From a design point of view, it makes sense to me to only
specify ONCE that largeish-collection-of-classes-A depends on
largeish-collection-of-classes-B. As another simple small example: say
I change the name of large-collection-of-classes-B - this way I only
need to do it once, else I need to grep and sed all over in order to do
it.

It just feels cleaner and easier.

I know essentially, if you stick to having many classes in a python
module, you have what I referred to in the previous paragraph, because
you can stick to importing other modules at the beginning of a module
and so have them and their contens available in the entire file.

Still, I'm investigating whether I can bend the ever-so-flexible python
to work well with my admittedly somewhat strange requirement. And, off
course, I'd like to hear what others think.

-i

[John Roth]

"Iwan Vosloo" <[e-mail] t> wrote in message
news:11******** **************@ g14g2000cwa.goo glegroups.com.. .

I know my foreign (to python) one class per module idea is what makes
life more difficult for me here. And there is an argument to be made
out that it is a stupid remnant I stick to from having used it in other
programming languages (do I have to admit C++ in my background?) Two
small examples of where it it useful for me: my development
environment is run by make to a large extent. Many standard UNIX tools
have the intelligence to deal with filenames, and if you know a file
corresponds to a class, you have a lot more info available in your
makefile.
Have you looked at using scons (http://www.scons.org/) instead
of make?
Also, if I use my version control software (currently gnu
arch) to see what's changed, for example, I get a list of changes files
which again gives me more info because I know a file corresponds to a
class. So, I can do a number of such small things using that convention that
works well with standard old UNIX tools. And I find that valuable.
Sometimes little conveniences lead to great big tar pits.
As for the dependencies- I'm trying to keep the specification of them
simple. From a design point of view, it makes sense to me to only
specify ONCE that largeish-collection-of-classes-A depends on
largeish-collection-of-classes-B. As another simple small example: say
I change the name of large-collection-of-classes-B - this way I only
need to do it once, else I need to grep and sed all over in order to do
it.

It just feels cleaner and easier.
This is what packages are for. As far as refactoring package alignments,
a little bit of scripting goes a long way. Sometimes trying to make an
existing tool do something that it's not really right for distorts the
entire
process, rather than simplifies it.

John Roth

-i