Page 1 of 2 12 Last
  • Jump to page:
    #1
  1. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2003
    Posts
    217
    Rep Power
    0

    Unhappy Module Questions


    I've these classes in different files.

    File 1:
    class socketDriver(pC.parseCommand):

    File 2:
    class parseCommand(cM.chanManagement, aM.authManagement):

    File 3:
    class authManagement:

    File 4:
    class chanManagement:

    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 03:56 PM.
  2. #2
  3. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Dec 2001
    Location
    Houston, TX
    Posts
    383
    Rep Power
    13
    Always directly import what you need. Yes, you could access them through the namespace in file 2, but don't.
  4. #3
  5. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2003
    Posts
    217
    Rep Power
    0
    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.
  6. #4
  7. Mini me.
    Devshed Novice (500 - 999 posts)

    Join Date
    Nov 2003
    Location
    Cambridge, UK
    Posts
    783
    Rep Power
    14
    XxChris,
    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
    Code:
    [File_1
        [File_2
             [File_3 ....]
             [File_4 ....]
        ]
    ]
    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
    Code:
    [File_1
        [File_3 ....]
        [File_4 ....]
        [File_2 ....]
    ]
    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:
    Code:
    #in file 1
    import file_3
    import file_4
    import file_2
    file_2.file_3 = file_3
    file_2.file_4 = file_4
    #this puts 3 and 4 in 2's namespace as well
    but this is IMO ugly coding which will get you into trouble on bigger projects.

    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.

    Grim
  8. #5
  9. Hello World :)
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Mar 2003
    Location
    Hull, UK
    Posts
    2,537
    Rep Power
    69
    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...

    Code:
    from module import *
    Edit: or listen to Grim he seems to understand what you wanted.

    Mark.
    Last edited by netytan; February 8th, 2004 at 05:41 PM.
    programming language development: www.netytan.com Hula

  10. #6
  11. Mini me.
    Devshed Novice (500 - 999 posts)

    Join Date
    Nov 2003
    Location
    Cambridge, UK
    Posts
    783
    Rep Power
    14
    Guys,

    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?]
    Grim,
  12. #7
  13. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2003
    Posts
    217
    Rep Power
    0
    Thanks, I understand the module stuff better now. But I'm still stuck on the inheritence vs. creating an instance, from my last post.
  14. #8
  15. Mini me.
    Devshed Novice (500 - 999 posts)

    Join Date
    Nov 2003
    Location
    Cambridge, UK
    Posts
    783
    Rep Power
    14
    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.

  16. #9
  17. Hello World :)
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Mar 2003
    Location
    Hull, UK
    Posts
    2,537
    Rep Power
    69
    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.

    Have fun,

    Mark.
    programming language development: www.netytan.com Hula

  18. #10
  19. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2003
    Posts
    217
    Rep Power
    0
    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 06:23 PM.
  20. #11
  21. Mini me.
    Devshed Novice (500 - 999 posts)

    Join Date
    Nov 2003
    Location
    Cambridge, UK
    Posts
    783
    Rep Power
    14
    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.

    Code:
    class myclass:
        def do_authentication(self):
             return TRUE #no authtication just okay everything
    
        def print_welcome(self):
             print "Hello ",
    
    class my_new_class(myclass):
       def do_authentication(self):
             #do the real code
             return result
    
       def print_welcome(self,name="Sid"):
             myclass.print_welcome(self)
             print name
    
      der new_function(self):
            print "Doing something new that myclass can't"
    
    old = myclass()
    old.print_welcome()
    #displays "Hello"
    a = my_new_class()
    a.print_welcome("fred")
    # displays "Hello fred"
    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.

    Grim
  22. #12
  23. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2003
    Posts
    217
    Rep Power
    0
    Here is the code that I'm trying to split up into modules:

    http://www.geocities.com/idontthinkalot/pybot.c

    It's a bit old than what I have now but the classes are the same.
    Last edited by XxChris; February 8th, 2004 at 07:07 PM.
  24. #13
  25. Mini me.
    Devshed Novice (500 - 999 posts)

    Join Date
    Nov 2003
    Location
    Cambridge, UK
    Posts
    783
    Rep Power
    14
    Hi XxChris,
    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:
    Code:
    #perhaps something like this..
    class socketDriver:
           def __init__(self):
                self.socket etc
                .....
           def connect(self):
                ....
           def send(self,data):
                ....
           def receive(self):
               .....
               return data
               
    class authManagement:
          ......
    class chanManagement:
          ......
    
    class parseCommand(socketDriver, authManagement, chanManagement):
    
           def mapCommand(self.... 
                .....
           def parseInput(self...
                .....
    
           def getdata(self):
                input = self.receive()
                if input.startswith('PING'):
                     self.send('PONG : PING\n\r')
                     print 'PONG has been sent.'
                elif input:
                     self.parseInput(input)            
    
    myBot = parseCommand()
    myBot.connect()
    while True:
         myBot.getData()
    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?
    No offence intended - I found your code very readable and clear and would not have been able to comment otherwise.
    Grim.
  26. #14
  27. Mini me.
    Devshed Novice (500 - 999 posts)

    Join Date
    Nov 2003
    Location
    Cambridge, UK
    Posts
    783
    Rep Power
    14
    and the modules bit:
    in pybot
    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.
  28. #15
  29. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Dec 2001
    Location
    Houston, TX
    Posts
    383
    Rep Power
    13
    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
Page 1 of 2 12 Last
  • Jump to page:

IMN logo majestic logo threadwatch logo seochat tools logo