I still can't quite see why you object so strongly to inheritance, as in many situations it provides a much cleaner solution than the procedural approach. For instance, take the following code:
class Player(object):
def examine(self, name)
item = self.find_item(name)
item.on_examine(self)
def take(self, name):
item = self.find_item(name)
item.on_take(self)
def message(self, text):
print text
def kill(self, killer):
self.message("You were killed by a " + killer)
class Item:
def __str__(self):
return self.name
def on_examine(self, player):
player.message(self.description)
def on_take(self, player):
self.container.remove(self)
player.inventory.append(self)
class LiveGrenade(Item):
name = "live grenade"
description = "Look out! It's a live grenade!"
def on_take(self, player):
player.message("Kaboom! The grenade exploded when you picked it up!")
player.kill(self)
The LiveGrenade class uses inheritance to override the on_take method. Indeed, the whole point of the OOP approach is that what a method actually does should be left up to the object. You're essentially just giving an object a message, and leaving the implementation up to it.
If I wanted to modify the above code to support multiple players, that wouldn't be too hard, either. I could have Player.message send the message to a TCP socket, rather than to STDOUT. I could even leave out the definition of the message method altogether, and have subclasses inheriting from it for single and multiplayer modes.
I'm curious as to how you'd write the above in a procedural style, and yet still retain the future flexibility that inheritance allows. For instance, let's say I wanted to have a squeaky toy:
class SqueakyToy(Item):
def on_take(self, player):
player.message("It squeaks as you pick it up")
Item.on_take(self, player)
Or a gorgon head:
class GorgonHead(Item):
def on_examine(self, player):
player.message("As you look at it, you turn to stone")
player.kill(self)
I don't see how this makes the code any less maintainable. It seems to do quite the opposite, in fact!