On 03/14/2012 04:37 PM, James Amundson wrote:
I have a use case involving Boost Serialization and Boost Python. I have a (mostly) C++ library wrapped with Python. The C++ code uses Boost Serialization to periodically create checkpoints from which the user can resume later. Getting the serialization and python libraries to work together didn't present any special problems until I had a case in which the user had a derived Python class (from a C++ base). In searching the web, I have seen people asking about similar cases, but never an answer. See, e.g., http://stackoverflow.com/questions/7289897/boost-serialization-and-boost-python-two-way-pickle <http://stackoverflow.com/questions/7289897/boost-serialization-and-boost-python-two-way-pickle> .
It's been a long while since I last tried to pickle Boost.Python objects, but I do recall being a lot happier with the level of control I had when I just implemented my own __reduce__ methods rather than relying on the __getstate__ and __setstate__ defined by enable_pickling(). In many cases, it was most convenient to actually just write __reduce__ in pure-Python and add it to the wrapped classes in the __init__.py file. It would have to delegate to wrapped C++ methods to do the Boost.Serialization calls, of course.
Using __reduce__ would allow you to provide a specific callable to reconstruct the Python derived class, which could then ensure it does exactly the right combination of regular unpickling and C++ deserialization.
Sorry that's not the review of your "almost there" solution you were looking for, but I do think you might find the problem easier to solve with __reduce__.
Jim _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
