Pickling/unpickling alternative (API-compatible) class implementations
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?
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__, i.e. foo.fastOctant.Octant.__class__.__module__='mupif.Octree'? Can it have some side-effects I don't see yet?