Python Programming On Win32

Designing COM Servers

We want to expose the Transaction and BookSet classes as COM servers. In Chapter 5, we saw an example of how a few simple additions can turn any Python class into a COM server. Now that our classes are larger and more complex, this isn’t always the best solution, and it’s worth thinking about alternatives. The basic problem is that COM-exposed methods sometimes need to handle their arguments in a different way than ordinary Python methods. For example, if a COM client such as Visual Basic calls the save method of our BookSet, it passes in a Unicode string, which needs to be converted to a Python string:

# our ordinary save method for use from Python
def save(self, filename):
    f = open(filename,'wb')
    cPickle.dump(self.__journal,f)
    f.close()

# what we would need for use from COM
def save(self, unicode_filename):
    # convert it to a python string:
    python_filename = str(unicode_filename)

    f = open(python_filename,'wb')
    cPickle.dump(self.__journal,f)
    f.close()

Furthermore, the whole philosophy of COM is about defining a fixed interface and sticking to it. This strongly suggests building a separate class for the COM interface and hooking it to our native Python classes, which can be far more dynamic. Here are several design patterns to do this:

COM base class, pure Python subclass

Here you define a base class and expose it as a COM server, initially doing nothing with the arguments to the methods, which defines your COM interface neatly in one place. Then implement a subclass ...