What are modules really for?

[Neil Benn]

Tito wrote:

>N.Davis wrote:
>  
>
>>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.
>>    
>>
>
>Well, all data in a Python program are objects, in the sense that they 
>have an identity on their own, and variables are only references to them.
>
>Why is it necessary to have all code into classes for meeting the 
>"everything is an object" panacea?
>  
>
If you don't have a class how can you combine functionality with data 
and hold state - that is one of the points of a class.  Python has the 
added concept that if you don;t need this you can create functions with 
no associations - lots of languages do that but Java, Eiffel, C#, etc 
don't have that concept.  You need to make a difference between 
everything is an object and everything is a class here.  A programmer 
coming from Java/C# wouldn't think about that.

>  
>
>>Even 
>>a static method is simply a class function that operates on the 
>>"collection of all instances" rather than a single instance.
>>    
>>
>
>That is not true. A static method knows nothing about the instances of a 
>  class, unless you do it your own. Besides, it will work whether you 
>have created instances of the class or not.
>
>So, a static method is just a global method declared withing a class, 
>which just serves as a namespace for it.
>  
>
In java, a static method is the same as a class method in Python, you 
can then use the cls param to access class attributes (that is what teh 
OP implied).  However a static method can help with namespacing.  What 
looks better :

initialise_local_message_router()
objPublisher = get_publisher_from_local_router('bob')

or

LocalRouter.initialise()
objPublisher = LocalRouter.getPublisher('bob')

    IMHO, the second case makes much more sense that a floating function 
which makes things less expressive.

>  
>
>>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?
>>    
>>
>
>Question back: why do you think having classes defined in the same file 
>compromises encapsulation? Classes don't know more about each other for 
>the fact of being written into the same file. Anyway, in Python, classes 
>know always too much from each other, don't they?, as there are no 
>access modifiers for class attributes.
>  
>
If I want to change one class and replace the file on the install then I 
need to put a whole bunch of classes on - increasing the change of 
making a mistake.  Module scoping exists with globals, also you have the 
convetnion of creating classes with the name of _XXX to mean module 
level only.

>  
>
>>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".
>>    
>>
>
>Well, that is the case with whatever general-purpose programming 
>language. You have virtually an infinite number of ways to do things, 
>and most of them are not appropriate.
>  
>
Some languages are more strict than others - yes you need covnentions 
but you will need more conventions in a less strict language.  The 
upside is that, if you are careful, you can leverage the added oosness 
to implement features which would be a pain in other languages.  
Enterprise systems have different objectives than a cgi script or single 
client install stuff.  It's a judgement call.

>The thing with Python is, in my opinion, that it wants to put all the 
>power in your hands to do whatever you want in the fastest way possible. 
>If I want to do something, I don't declare a class that knows how to do 
>it, then create it and invoke the right method, I just put the code to 
>do what I want to do. If, in between, I find that one class would make 
>my life easier, I declare it just in place and go on. If I find 
>repetitive tasks I can declare functions, but I won't go for a class 
>immediately. Why do you think putting code into functions is not 
>encapsulating?
>
>  
>
>>While you could do all manner 
>>of nasty hacks in C++ I worked with people who carefully avoided this.
>>    
>>
>
>Well done, but messes you can do in whatever language.
>  
>
Agreed but in some languages you can cause more havoc than in others, 
look at the distinction .NET makes between managed and unmanaged code to 
get a handle on this.

>Regards,
>Tito
>  
>
Cheers,

Neil

-- 

Neil Benn
Senior Automation Engineer
Cenix BioScience
BioInnovations Zentrum
Tatzberg 47
D-01307
Dresden
Germany

Tel : +49 (0)351 4173 154
e-mail : benn at cenix-bioscience.com
Cenix Website : http://www.cenix-bioscience.com