February 8th, 2004, 02:42 PM
I've these classes in different files.
class parseCommand(cM.chanManagement, aM.authManagement):
I import File 2 from File 1 because socketDriver needs pC. Now, my question is: why can't I just put the aM and cM imports into File 1 too? At the momment they're in File 2, because otherwise it doesn't work. Also, parseCommand and socketDriver use the 'sys' module. Why do I need to import it into both File 1 and File 2 if File 2 is being imported into File 1 (it's already in File 1).
This module scope stuff is crazy. I hope I made sense...
Last edited by XxChris; February 8th, 2004 at 02:56 PM.
February 8th, 2004, 03:51 PM
Always directly import what you need. Yes, you could access them through the namespace in file 2, but don't.
February 8th, 2004, 04:19 PM
I have a class for socket stuff, chan management stuff and auth management stuff, should I use inheritence for to be able to use the methods from the other classes or create an instance of them and call it that way? I'm not sure when to use which.
February 8th, 2004, 04:29 PM
A bit wordy but I hope this is helpful (appologies if this is sucking eggs to you) . The problem is namespace, the structure of the namespace depends on the sequence of imports. To describe this I've used  to indicate the namespaces for each module.
Your working code ver A
File 1 can see everything in 2,3 and 4 because they are within it's namespace. File 2 can see stuff in 3 and 4 but not in 1. From 1, references to objects in 3 and 4 would be via 2, like file_2.file_3.object and file_2.file_4.object
How you want it ver B
With ver B, as before, file 1 can see everything in 2,3 and 4. But this time file 2 cannot see stuff in 3 and 4 because it has no reference to them (it didn't import them). This means that file 2 cannot create objects that reference objects/classes defined in 3 or 4. You can do tricks like:
but this is IMO ugly coding which will get you into trouble on bigger projects.
#in file 1
file_2.file_3 = file_3
file_2.file_4 = file_4
#this puts 3 and 4 in 2's namespace as well
One OO approach would be to keep your original structure and anytime file 1 needs to get file 3,4 stuff wrap it in a file 2 function. This way if you ever re-use or ditsribute file_2 you don't have to remember what it depends on to drive the module and you only need to document file_2 functions and attributes.
February 8th, 2004, 04:32 PM
Like strike said, you should import whatever you need directly... i'm not sure excatly what you mean but whats the problem with importing what you need into each file?
If you really dont want to import the classes why not just put them all in one file? or get the same effect by using the from import format...
Edit: or listen to Grim he seems to understand what you wanted.
from module import *
Last edited by netytan; February 8th, 2004 at 04:41 PM.
February 8th, 2004, 04:41 PM
It's personal preferences - of course - but a socket is a low level thing, a session might be considered to use a socket, authentication, and a channel so in my book I would consider wrapping all these things in session class. The authentication bit would be ideal as a mixin.
my 2 cents!
[is session the right term here?]
February 8th, 2004, 04:44 PM
Thanks, I understand the module stuff better now. But I'm still stuck on the inheritence vs. creating an instance, from my last post.
February 8th, 2004, 04:57 PM
In a slightly off the wall moment :
Does anyone cook?
A lot of receipe books have lots of sauce receipes. To save repetition they often they use a base sauce and add things to it. So the other sauce receipes often start like:
1. make your base sauce
2. add ingredient x and chill
3. cook slowly.
You can see where i'm going with this
1 is a base class sauce, after step 2 you have a new class sauce inheriting all the attributes of the original sauce excpet it has now got an x attribute and a chill method. At step 3 when you cook it you have an instance of the new class sauce and you can actually eat it.
February 8th, 2004, 05:02 PM
The main difference between inheritance and an instance is that inherting from a class gives you a copy of that class which you can build on, alter and create instances of. Where an instance is exactly that, an instance of the class and can only be used, and not altered or built on.
Hope you got that , not the easiest thing in the world to explain.
February 8th, 2004, 05:15 PM
I understand that stuff, but I have classes that need a bit of functionality from eachother. Do I use inheritence so I can call those methods or do I do: myInstance = myClass() then call myInstance.method() from the classes which need it. At the moment some of the base classes need to use a method or two from derived classes and vice versa. Bah... OOP is confusing...
Last edited by XxChris; February 8th, 2004 at 05:23 PM.
February 8th, 2004, 05:45 PM
If you inherit methods from a base class they are your methods too! You would not have to refer to the base class. (Except legitimately in functions like __init__ where the undelying base.__init__ is often called by the new classes __init__ method. Usually because it does things you cant see like allocate memory or does all you want but you wish to add a bit more to it ).
Inheritence means you get every thing from the parent, but if you wish you can change it.
IMHO If you can't structure it this way then maybe you need to re-visit the design. OOP is about encapsulation of functionality that defines an object in that object. If that functionailty criss crosses between different objects then its a bit broken.
return TRUE #no authtication just okay everything
print "Hello ",
#do the real code
print "Doing something new that myclass can't"
old = myclass()
a = my_new_class()
# displays "Hello fred"
February 8th, 2004, 05:47 PM
February 9th, 2004, 06:15 AM
IMO nothing wrong with your code but if you are looking for suggestions:
Your socketDriver is inheriting all the other classes but creates the socket object that those classes use. This suggests that the socket is a fundamental attribute and would be better defined in a base class. So I recommend you make socketDriver the base class.
This is a matter of personal taste but when deciding if stuff should be in a class at all it's useful for me to think about what it is I want. For example your class parseCommand is "doing something" and not "being something" so parseCommand.parseInput, parseCommand.mapCommand could just as easily be defined as individual support functions. These are then passed the self.sock as a parameter.
In your code, authManagement calls self.sock.send directly. If you were to add a send method to socketDriver then authManagement could call self.send without knowing it has an underlying socket. This encapsulates the socket in the socketDriver class so next time you want to change your code to support wet-string protocol instead of TCP/IP you only change the code for the one send method and as a bonus authManagement becomes more reusable/general. The same for chanManagement. auth/chan become "mixin" type classses.
If you keep parseCommand as a class then:
I find choosing a name for a class often the most difficult bit! Thats because I know if I choose a good name it helps me write the code. Why not rename parseCommand as pyBot?
#perhaps something like this..
class parseCommand(socketDriver, authManagement, chanManagement):
input = self.receive()
self.send('PONG : PING\n\r')
print 'PONG has been sent.'
myBot = parseCommand()
No offence intended - I found your code very readable and clear and would not have been able to comment otherwise.
February 9th, 2004, 06:21 AM
and the modules bit:
from socketDriver import *
from chanManagement import *
from authManagement import *
But personally I don't like using * as I don't know if different modules have used the same names.
February 9th, 2004, 08:52 AM
Don't use from <module> import *. It's very bad style. The only reason it's even still around is for simple stuff in the interpreter, for trivial cases of importing everything, and for backwards compatibility. But stomping all over the whole namespace mechanism in real code is not what it's there for