> <boiled down version of George's exmaple> I'm not sure if it was clear to you, but my problem is the dummy WorldModel_v1.MovableObject class. It doesn't do anything by itself, but it has to be in the inheritance chain to make its descendants work properly.
> Are you using the *_v1 naming convention for backwards compatibility? > Backwards compatibility is a giant pain in the ass, I notice you are > posting from a .edu address so if this is just something you are working > on by yourself or in a small group drop the versioning aspects from the > code. Sure, if there was a single version there would be no need for this post, but that's not the point; backwards compatibilty is part of the sad reality. I'm trying to write a client for a framework that has gone through 9 protocol version changes so far and now goes for the 10th. There are 5-7 different game object classes, so this makes 50-70 classes overall for the ten versions. Most of them would be dummy like the WorldModel_v1.MovableObject in the example. So the candidate solutions so far are: 1. Write the dummy classes by hand. 2. Generate them on the fly using some metaprogramming technique (introspection/metaclass/?) 3. Find an appropriate design pattern that avoids the need for the dummy classes. Any ideas for (2) or (3) ? George -- http://mail.python.org/mailman/listinfo/python-list