Pickling/unpickling alternative (API-compatible) class implementations

Question

In a distributed computing project, we are using Pyro to pass objects over the wire between nodes; Pyro internally serializes and deserializes objects using pickle.

Some classes in the project have two implementations: one pure-Python (for ease of installation, especially for Windows users), one in c++/boost::python (much faster, but requires boost + knowledge of how to compile the extension module). Both python and c++ classes support pickling (in c++, that is done via boost::python).

These classes have different fully-qualified name ( mupif.Octree.Octant vs. mupif.fastOctant.Octant ), but the latter is aliased to the former and overwrites the pure-Python definition ( mupif.Octree.Octant=mupif.fastOctant.Octant ), so it is transparent to the user and the fast variant is always used if available on the node.

However, pickle uses __module__ and __class__ to identify the instance, thus when the c++-based object is passed over the wire to another node which does not support it, unpickling will fail.

What is a solution to this? Is it acceptable to change the classe's __module__ , ie foo.fastOctant.Octant.__class__.__module__='mupif.Octree' ? Can it have some side-effects I don't see yet?

Answer 1

Does it help to alias in another way (fast = normal) if there is no fast implementation available? Maybe this could be done only for the time of unpickling and then reversed, to avoid confusing checks in other code?