1

I'm currently writing a wrapper in python for a lot of custom company tools.

I'm basically going to break each tool into its own py file with a class containing the call to the tool as a method. These will all be contained in a package.

Then there'll be a master class that will import all from the package, then inherit from each and every class, so as to appear as one cohesive class.

masterClass.py

pyPackage
- __ init__.py

- module1.py
--class Module1
---method tool1

- module2.py
--class Module2
---method tool2

etc

Right now, I'm autogenerating the master class file to inherit from the packages modules, but I was wondering if there was a more elegant way to do it?

ie

from package import *
class MasterClass(package.all):
    pass
Dhruv Govil
  • 349
  • 1
  • 3
  • 13
  • This sounds like Java and not Python code. E.g. in Python you don't have a `all` module (and if you want a `all` module, you would use `__init__.py`) And what you describe are mixins. – dav1d Sep 04 '12 at 21:10
  • sorry, meant import * not import all with __all__ defined in the __init__ – Dhruv Govil Sep 04 '12 at 21:12
  • Then there is no way to do it (if you ignore the hacks with `dir()` and `eval`). – dav1d Sep 04 '12 at 21:13
  • Ya I too would love to know how you are doing this right now. It seems like it could potentially cause problems, having one class dynamically inherit from many many other classes. What about potential naming conflicts? I also don't understand why class inheritance makes sense for this. Why not just access the tools from the master class as a single entry point? What does a huge single class give you? – jdi Sep 04 '12 at 21:14
  • The single class is for ease of use because of the port system being used. The port connection exists as an object that needs to be passed to each function to work properly. Whereas if I have it inside a class as methods, I can init this value once as self.port and then every action can just use that one object. – Dhruv Govil Sep 04 '12 at 21:35
  • Thats a base class. See my answer. – jdi Sep 04 '12 at 21:36
  • @jdi,sorry I should clarify. I want the opposite of a base class because the port object is dynamically created on the script initialization and needs to be passed to the class. If I put it in a base class, I'd have to pass the object to each inheriting class creating a lot of unnecessary overhead – Dhruv Govil Sep 04 '12 at 21:43
  • What about base class with a shared class-level port object? – jdi Sep 04 '12 at 21:45

1 Answers1

0

I am not really sure what your reasons are for trying to create a larger master class with inheritance from all of your other smaller classes, but the first thing that comes to mind is that the design might be backwards.

What you might want to do instead is have a base class, for which all your command modules can subclass. You can use packages as intelligent namespaces for collecting similar functionality such as "network" or "compression", etc.

class ToolBase(object):
    # common functionality here

    # class attributes

    # base constructor

    # methods: static, class, instance

    pass


class Module1(ToolBase):

    def __init__(self):
        super(Module1, self).__init__()

class Module2(ToolBase):

    def __init__(self):
        super(Module2, self).__init__()

In this base class example, every subclass can expect the functionality of ToolBase to be there, including any setup from the constructor like a database connection, sockets, resource.

And maybe a project structure like this:

pyPackage
    __init__.py 
        # class ToolBase
        # __all__ = ['network', 'compress']
    network/
        __init__.py
        module1.py
            # class Module1
    compress/
        __init__.py 
        module2.py
            # class Module2

Update

As a way to use the base class and have a shared "port" object, you could make it a class level attribute that is only initialized once:

class ToolBase(object):
    _PORT = None

    def __init__(self):
        if self._PORT is None:
            self._PORT = "PORT"

    @property 
    def port(self):
        return self._PORT


class Foo(ToolBase):

    def go(self):
        print self.port

Now your classes are useful on their own, and will share the port object.

jdi
  • 90,542
  • 19
  • 167
  • 203
  • Well it's because each function needs a port object to work, but that port object is dynamically created on initialization. So rather than passing the port to each and every method, it's a lot cleaner (to me) to inherit all of them, and then just pass the port once – Dhruv Govil Sep 04 '12 at 21:37
  • This doesn't sound like they should be separate classes then. If they all rely on a port object, and you are creating the port object in your master class...then it would make the original classes abstract and unusable on their own. – jdi Sep 04 '12 at 21:40
  • They would never be used on their own. The reason for breaking them out into seperate classes was for easy modification to them. Currently they exist as one extremely large class. ie. basically I want to split this one large class py script into several smaller ones, but keep the end accesability the same – Dhruv Govil Sep 04 '12 at 21:46
  • Thanks. I will try that. :-) In the meantime, this post had some good suggestions to my problem too http://stackoverflow.com/questions/9638446/is-there-any-python-equivalent-to-partial-classes The reason being that my class was in excess of 10k lines(though I've since slimmed down considerably) – Dhruv Govil Sep 04 '12 at 21:58
  • This is a very strange design, and if the only reason is to avoid passing *one* value to the functions, then it really isn't worth it. Pass the port to the functions and be done with it. – Ned Batchelder Sep 05 '12 at 01:32
  • @NedBatchelder: Are you referring to my answer, the design the OP wanted, or the comment that was previous written about that other question suggesting a design? – jdi Sep 05 '12 at 01:38