ansaurus

Question

[Python] Discussion of multiple inheritance vs Composition for a project (+other things)

Answer 1

+1 A:

super calls the next class in the mro-list. This works even if you leave out the __init__ form some class.

class A(object):
  def __init__(self):
    super(A,self).__init__()
    print "Hello from A!"

class B(A):
  def __init__(self):
    super(B,self).__init__()
    print "Hello from B!"

class C(A):
  def __init__(self):
    super(C,self).__init__()
    print "Hello from C!"

class D(B,C):
  def __init__(self):
    super(D,self).__init__()
    print "Hello from D!"

class E(B,C):
  pass

Example:

>>> x = D()
Hello from A!
Hello from C!
Hello from B!
Hello from D!
>>> y = E()
Hello from A!
Hello from C!
Hello from B!
>>>

Edit: Rewrote the answer. (again)

MizardX 2009-03-14 07:44:16

(Note: This will still call the base class at the peak of the class inheritance diamond three different times, with potentially disastrous results.)

cdleary 2009-03-14 08:08:20

Answer 2

+1 A:

Here's a partial solution:

class NodeMeta(type):
    def __init__(cls, name, bases, d):
     setattr(cls, '__inherits__', bases)

class Node(object):
    __metaclass__ = NodeMeta

    def __init__(self):
     for cls in self.__inherits__:
      cls.cls_init(self)

class Sensor(Node):
    def cls_init(self):
     print "Sensor initialized"

class PositionSensor(Sensor):
    def cls_init(self):
     print "PositionSensor initialized"
     self._bearing = 0

    def bearing(self):
     # calculate bearing:
     return self._bearing

class BearingSensor(Sensor):
    def cls_init(self):
     print "BearingSensor initialized"
     self._position = (0, 0)

    def position(self):
     # calculate position:
     return self._position

# -------- custom sensors --------

class CustomSensor(PositionSensor, BearingSensor):
    def think(self):
     print "Current position:", self.position()
     print "Current bearing:", self.bearing()

class CustomSensor2(PositionSensor, BearingSensor, Sensor):
    pass

>>> s = CustomSensor()
PositionSensor initialized
BearingSensor initialized
>>> s.think()
Current position: (0, 9)
Current bearing: 0

You'll have to move your __init__ code from the Node subclasses into some other method (I used cls_init).

Edit: I posted this before I saw your updates; I'll re-read your question, and if necessary, update this solution.

elo80ka 2009-03-14 09:14:50

Answer 3

+4 A:

The sensor architecture can be solved by using composition if you want to stick to your original map-of-data design. You seem to be new to Python so I'll try to keep idioms to a minimum.

class IRSensor:
    def read(self): return {'ir_amplitude': 12}

class UltrasonicSensor:
    def read(self): return {'ultrasonic_amplitude': 63}

class SickLaserSensor:
    def read(self): return {'laser_amplitude': 55}

class CompositeSensor:
    """Wrap multiple component sensors, coalesce the results, and return
    the composite readout.
    """
    component_sensors = []

    def __init__(self, component_sensors=None):
        component_sensors = component_sensors or self.component_sensors
        self.sensors = [cls() for cls in component_sensors]

    def read(self):
        measurements = {}
        for sensor in self.sensors:
            measurements.update(sensor.read())
        return measurements

class MyCompositeSensor(CompositeSensor):
    component_sensors = [UltrasonicSensor, IRSensor]


composite_sensor = MyCompositeSensor()
measurement_map = composite_sensor.read()
assert measurement_map['ultrasonic_amplitude'] == 63
assert measurement_map['ir_amplitude'] == 12

The architectural problem you're describing with the actuators is solved by using mixins and proxying (via __getattr__) rather than inheritance. (Proxying can be a nice alternative to inheritance because objects to proxy to can be bound/unbound at runtime. Also, you don't have to worry about handling all initialization in a single constructor using this technique.)

class MovementActuator:
    def __init__(self, x=0, y=0):
        self.x, self.y = (x, y)

    def move(self, x, y):
        print 'Moving to', x, y
        self.x, self.y = (x, y)

    def get_position(self):
        return (self.x, self.y)

class CommunicationActuator:
    def communicate(self):
        return 'Hey you out there!'

class CompositeActuator:
    component_actuators = []

    def __init__(self, component_actuators=None):
        component_actuators = component_actuators \
            or self.component_actuators
        self.actuators = [cls() for cls in component_actuators]

    def __getattr__(self, attr_name):
        """Look for value in component sensors."""
        for actuator in self.actuators:
            if hasattr(actuator, attr_name):
                return getattr(actuator, attr_name)
        raise AttributeError(attr_name)


class MyCompositeActuator(CompositeActuator):
    component_actuators = [MovementActuator, CommunicationActuator]

composite_actuator = MyCompositeActuator()
assert composite_actuator.get_position() == (0, 0)
assert composite_actuator.communicate() == 'Hey you out there!'

And finally, you can throw it all together with a simple node declaration:

from sensors import *
from actuators import *

class AbstractNode:
    sensors = [] # Set of classes.
    actuators = [] # Set of classes.
    def __init__(self):
        self.composite_sensor = CompositeSensor(self.sensors)
        self.composite_actuator = CompositeActuator(self.actuators)

class MyNode(AbstractNode):
    sensors = [UltrasonicSensor, SickLaserSensor]
    actuators = [MovementActuator, CommunicationActuator]

    def think(self):
        measurement_map = self.composite_sensor.read()
        while self.composite_actuator.get_position()[1] >= 0:
            self.composite_actuator.move(100, -100)

my_node = MyNode()
my_node.think()

That should give you an idea of the alternatives to the rigid type system. Note that you don't have to rely on the type hierarchy at all -- just implement to a (potentially implicit) common interface.

LESS OLD:

After reading the question more carefully, I see that what you have is a classic example of diamond inheritance, which is the evil that makes people flee towards single inheritance.

You probably don't want this to begin with, since class hierarchy means squat in Python. What you want to do is make a SensorInterface (minimum requirements for a sensor) and have a bunch of "mixin" classes that have totally independent functionality that can be invoked through methods of various names. In your sensor framework you shouldn't say things like isinstance(sensor, PositionSensor) -- you should say things like "can this sensor geo-locate?" in the following form:

def get_position(sensor):
    try:
        return sensor.geolocate()
    except AttributeError:
        return None

This is the heart of duck-typing philosophy and EAFP (Easier to Ask for Forgiveness than Permission), both of which the Python language embraces.

You should probably describe what methods these sensors will actually implement so we can describe how you can use mixin classes for your plugin architecture.

OLD:

If they write the code in a module that gets put in a plugin package or what have you, you can magically instrument the classes for them when you import their plugin modules. Something along the lines of this snippet (untested):

 import inspect
 import types

 from sensors import Sensor

 def is_class(obj):
     return type(obj) in (types.ClassType, types.TypeType)

 def instrumented_init(self, *args, **kwargs):
     Sensor.__init__(self, *args, **kwargs)

 for module in plugin_modules: # Get this from somewhere...
     classes = inspect.getmembers(module, predicate=is_class)
     for name, cls in classes:
         if hasattr(cls, '__init__'):
             # User specified own init, may be deriving from something else.
             continue 
         if cls.__bases__ != tuple([Sensor]):
             continue # Class doesn't singly inherit from sensor.
         cls.__init__ = instrumented_init

You can find the modules within a package with another function.

cdleary 2009-03-14 12:11:31

+1: Composition usually works out better than complex inheritance hierarchies.

S.Lott 2009-03-14 12:33:55

Answer 4

A:

Have you written the simulator. Will you share it with other people?

2009-04-24 04:59:47

I will be releasing it under some open-source license once I've finished developing it, although it has evolved significantly since the posting of this question. For the mean time, you may be interested in www.swarmrobot.org

Mike Hamer 2009-05-03 16:43:46

ansaurus

tags:

views:

answers:

[Python] Discussion of multiple inheritance vs Composition for a project (+other things)

NEW EDIT:

OLD THINGS:

LESS OLD:

OLD:

related questions