A class is more or less a fancy wrapper for a dict of attributes to objects. When you instantiate a class you can assign to its attributes, and those will be stored in foo.__dict__; likewise, you can look in foo.__dict__ for any attributes you have already written.

This means you can do some neat dynamic things like:

class Employee: pass
def foo(self): pass
Employee.foo = foo

as well as assigning to a particular instance. (EDIT: added self parameter)

When you create a new class, you are creating a new type. This newly created type may have some properties, or may not. These properties allow to hold data, methods etc.

Empty class that doesn't inherit any base class would be useful as placeholder.

class ServiceWrapper(object):
    pass

def sendMessage(svc:ServiceWrapper):
    #do something
    #pass

On the other hand, empty classes that inherit other classes is a very common pattern. Specially when defining user exceptions.

class Networkerror(RuntimeError):
    pass

try:
    raise Networkerror()
except Networkerror:
    #do something
    #pass

Also recently, the python collections.abc allows creating interface like functionalities.

class ServiceWrapper(ABC):
    @abstractmethod
    def send(self):...

def sendMessage(svc:ServiceWrapper):
    svc.send()
    #pass

This is just fine:

class Parent:
    # the __init__ is inherited from parent
    pass

class Child(Parent):
    # the __init__ is inherited from parent
    pass

This is also fine:

class Parent:
    # the __init__ is inherited from parent
    pass

class Child(Parent):
    def __init__(self):
        # __init__ is called on parent
        super().__init__()

This may seem ok, and will usually work fine, but not always:

class Parent:
    # the __init__ is inherited from parent
    pass

class Child(Parent):
    def __init__(self):
        # this does not call parent's __init__, 
        pass

Here is one example where it goes wrong:

class Parent2:
    def __init__(self):
        super().__init__()
        print('Parent2 initialized')


class Child2(Child, Parent2):
    pass

# you'd expect this to call Parent2.__init__, but it won't:
Child2()

This is because the MRO of Child2 is: Child2 -> Child -> Parent -> Parent2 -> object.

Child2.__init__ is inherited from Child and that one does not call Parent2.__init__, because of the missing call to super().__init__.

^{Note: This post contains two different implementation techniques to allow for what you want.}

Solution Through Indirection

The easiest way around this issue is to refactor the code so that the child classes does not directly override the function used by the public interface.

Instead provide the public functionality directly in the base-class, and make children override a "worker" (implementation detail) of said function that is later called by the function invoked "from the outside".

Example Implementation

class Base (object):
    def get_message (self):
        try:
            return self.get_message_impl ()
        except Exception as detail:
            print ("error:", detail)    
        return None

    def get_message_impl (self):
        raise Exception ("Not Implemented")

class Foo (Base):
    def get_message_impl (self):
        return "Hello World";

class Bar (Base):
    def get_message_impl (self):
        raise Exception ("Bar.get_message_impl always fails!")

f = Foo ()
b = Bar ()

f_msg = f.get_message ()
b_msg = b.get_message ()

print ("f_msg:", f_msg)
print ("b_msg:", b_msg)

output

error: Bar.get_message_impl always fails!
f_msg: Hello World
b_msg: None

opt-in protection

If you would like to maintain the possibility to override the public functionality presented in the base class, while still being able to easily call a "protected" version of the functions at a later time, you could create a simply wrapper such as the below:

class Base (object):
    class Protected (object):
        def __init__ (self, target):
            self.target = target

        def get_message (self):
            try:
                return self.target.get_message ()
            except Exception as detail:
                print ("error:", detail)
            return None

    def __init__ (self):
        self.protected = self.Protected (self)

    def get_message (self):
        raise Exception ("Not Implemented")

class Foo (Base):
    def get_message (self):
        return "Hello World";

class Bar (Base):
    def get_message (self):
        raise Exception ("Bar.get_message_impl always fail!")

f = Foo ()
b = Bar ()

f_msg = f.protected.get_message () # protected from failure
b_msg = b.protected.get_message () # protected from failure

b_msg = b.get_message ()           # will raise exception

Yes, in Python 3.3 SimpleNamespace was added

Unlike object, with SimpleNamespace you can add and remove attributes. If a SimpleNamespace object is initialized with keyword arguments, those are directly added to the underlying namespace.

Example:

import types

x = types.SimpleNamespace()
x.happy = True

print(x.happy) # True

del x.happy
print(x.happy) # AttributeError. object has no attribute 'happy'

It sounds like you want a class factory:

def make_baked_type(fruit, bake):
    class baked_item(fruit, bake):
        pass
    return baked_item

ApplePie = make_baked_type(Apple, Pie)
item = ApplePie()
print(item.flavour())

# or
def make_baked_item(fruit, bake):
    return make_baked_type(fruit, bake)()

item = make_baked_item(Apple, Pie)
print(item.flavour())

Now that you've explained more fully, it seems that there really is no subclass-specific logic. In that case, inheritance is not the right choice. If there really are only minor ways in which other parts of the code treat products, putting code into product classes would be wrong - a violation of separation of concerns which would encumber the product classes with knowledge of other parts of your system. The sorting example makes that clear. Products should not know how they are sorted or stored or presented; if the code which sorts or presents objects is changed, the product class should not need to be rewritten.

I apologise for doubting you on that. We see so many people here presenting questions which are based on poor OO knowledge and I assumed this was the case when I should have asked for more info first.

In fact...

The method overloading choice, as shown in your example code, is actually going against principles like the separation of concerns and DRY. What is the common thing about the add_product method? It adds a product to the appropriate collection. But in the example code, that single, fundamentally identical task is duplicated in three different places. This is really scarcely different to a chain of if..then..else logic.

• The logic is duplicated and any changes to the common behaviour will have to be duplicated in each place. Mistakes are likely and will go undetected.
• The product-adding code should not need to know what types of products are available. All it needs to know is that there are a variety of products, each of which should be added to an appropriate collection. Making it aware means you have to change this section of the code every time you add a new product.

A better way to do this, if you really do need a separate collection for each type of product, would be to have a map of product collections. The key would be the product type. Then you could have one single product_add method, which consults that map and adds the product to the right place. Even if you discovered that there is some need for different product subclasses, this method doesn't need to know. The object class itself could be the key to the map, for example.

Since more than one method is likely to want to update or read from those collections, it is probably better to have a Products object which stores the objects. Whether it contains a map of N different collections or one collection which it knows how to filter/search by type is an implementation detail which need not concern other parts of your code.

In Summary

Since there really seems to be no product-specific code, extra empty classes are not only useless, they complicated your code and make it more fragile. A 'type' member is better.

• Most of your code doesn't even need to know that there is such a member.
• In each domain (the clearly separate sections of your application), identify those few bits which genuinely need to differentiate between product types.
• Isolate them in special helper classes or functions which will return the appropriate product (or do the appropriate thing which matches the type)
• Maps are very useful (they can contain not only collections but other helper objects/functions to hand back to some other code to do the appropriate thing with this object) but should be hidden from anything but the privileged code which really needs to be product-type aware.

If you do that, not only will your code be cleaner and more elegant (free from ugly if..then..else chains, for one thing), if you ever do find a real need for product subclasses, almost none of your existing code will have to change. And even they need only change their internal implementation, because their code will still be no concern of the product class or any of its subclasses.

There is still plenty of fun to be had with adding new classes in the respective domains to encapsulate any "I know what kind of products there are". One challenge is differentiating between the bits of those code which are domain specific (e.g. sorting in a collection which is only relevant in one domain) from those which are actually general. The list of all valid product types, for example, should be an enum which can be fetched by any product-aware domain-specific code. Any map should use that enum as the type for its key. Any function which takes a product "type" as a parameter should take a parameter only of that enum type and so on. Now, where in your code are you going to define that enum?

It seems to me your confusion stems from a misunderstanding of __init__ and your use of type. With type you can dynamically create new classes, but here you want to simply use previously defined classes. Whenever you indeed initialize such a class, your provided arguments are passed to the __init__ function, where you can do whatever you want with them.

I cleaned up your code and added comments to clarify the flow of things:

# Create a blueprint for Base
class Base:
    def print_something(self):
        print('Something.')


# Create a blueprint for A
class A(Base):
    # Do some initialization whenever an instance of A is created.
    def __init__(self):
        print('Initializing A without any args')
        # Do some initialization
        self.answer = 42


# Create a blueprint for B
class B(Base):
    # An __init__ method with arguments
    def __init__(self, foo, bar):
        print(f'Initializing B with args: {foo}, {bar}')
        self.foo = foo
        self.bar = bar


# Create a blueprint for C
class C(B, Base):
    # Do some initialization whenever an instance of C is created.
    def __init__(self, x):
        # Create an instance of A and store it as an attribute of the instance
        # of C that we are initializing here.
        self.a = A()
        # Do the same for B, but provide init arguments.
        self.b = B(x[0], x[1])


def main():
    # Create an instance of C
    c = C([1, 2])

    # Print some attributes to clarify the hierarchy
    print(c.a.answer)
    print(c.b.foo)
    print(c.b.bar)


if __name__ == '__main__':
    main()