What are modules really for?

[N.Davis]

Thanks very much for your helpful replies.
I totally accept my C++/Java background is a lot of this, and I need to 
make the shift to Python's way of thinking.
As for multiple inheritance, yes I've always been aware of it being 
available in C++, but I learned C++ at a company which banned multiple 
inheritance in their coding standards, with comments about "The GOTO of 
the 1990s". Like people here, I've no complaints about not using 
multiple inheritance. ;-) But Zope/Plone uses it therefore I have to 
understand it...
Functions existing in a module? Surely if "everything is an object" (OK 
thats Java-talk but supposedly Python will eventually follow this too) 
then there should be nothing in a module thats not part of a class. Even 
a static method is simply a class function that operates on the 
"collection of all instances" rather than a single instance.
Related classes in the same file? Be careful. Doesn't anything "knowing" 
about anything else compromise encapsulation? Why would 
properly-designed classes have such a close relationship?
Having back in the day worked on big real-time systems where being very 
strict about encapsulation was a god-send for fighting complexity, I 
feel unnerved by Perl and Python's laid-back OO culture of "you can do 
it if you feel like it but don't have to". While you could do all manner 
of nasty hacks in C++ I worked with people who carefully avoided this. 
Maybe that was just luck....

Thanks again. Python is great anyway.

:-)

Nick


> 
> 
> One reason is that functions need a place to exist too.  In Java, every
> function, even "static" ones has to be a class method.  In Python,
> "static" functions are best kept in a module.  Another thing is that
> packages were a later addition to the language.
> 
> 
>>To my mind, although one CAN put many classes in a file, it is better to
>>put one class per file, for readability and maintainability.
> 
> 
> Personally I find it easier to maintain a set of related classes when
> they're all in the same file.  I've got a few modules that I'm
> currently hacking on, each of which contains a handful of classes.
> Maybe it's just a matter of scale, since these are both fairly small
> libraries, but I just don't see any advantage to splitting them up into
> multiple files.
> 
> 
>>One can then create packages and libraries, using groups of files, one
>>class per file.
> 
> 
> Since Java's compiler enforces this, perhaps you've just come to accept
> it as "normal".
> 
> 
>>Python seems to let you group classes together in one file and call it a
>>module, but what for?
> 
> 
> What if one of your classes creates/manipulates other classes.  If
> they're in the same module then they all exist in the same namespace
> and you don't have to have modules importing each other or such things.
> 
> 
>>I find that this, combined with mixins, makes it difficult to find out
>>where code is inherited from.
> 
> 
> Perhaps you are relying too much on inheritance, then?
> 
> 
>>With single inheritance in C++ or Java, if you wanted to see what a
>>method did and it appeared to be inherited, you would simply look in the
>>base class's file, and if necessary recurse up the inheritance hierarchy
>>until you found the method.
>>
>>With Python an inherited method could be in one of many base classes
>>and/or mixins and there seems no particular logic as to what the
>>filename would be.
> 
> 
> It shouldn't be too hard to figure out, unless someone was being
> intentially vague.  You could always fire up the interpreter, import
> your class, and check it's .mro property (method resolution order),
> which lists the classes in the order they will be examined to find a
> method named at runtime.
> 
> 
>>Am I missing something?
> 
> 
> I just think you're thinking in terms of Java.  You'll pick things up
> quickly, though :-)
>