"tomer filiba" <tomerfiliba@gmail.com> wrote:
i'm having great trouble in RPyC with pickling object proxies. several users have asked for this feature, but no matter how hard i try to "bend the truth", pickle always complains. it uses type(obj) for the dispatching, which "uncovers" the object is actually a proxy, rather than a real object. [snip] also note that it makes the copy module much simpler: def copy(obj): state = obj.__getstate__() return type(obj).__setstate__(state)
I presume you mean... def copy(obj): typ, state = obj.__getstate__() return typ.__setstate__(state)
- - - - - - - - executive summary: simplifying object serialization and copying by revising __getstate__ and __setstate__, so that they return a "simplified" version of the object.
this new mechanism should become an official API to getting or setting the "contents" of objects (either builtin or user-defined).
having this unified mechanism, pickling proxy objects would work as expected.
if there's interest, i'll write a pep-like document to explain all the semantics.
Overall, I like the idea; I'm a big fan of simplifying object persistence and/or serialization. A part of me also likes how the objects can choose to lie about their types. But another part of me says; the basic objects that you specified already have a format that is unambiguous, repr(obj). They also are able to be reconstructed from their component parts via eval(repr(obj)), or even via the 'unrepr' function in the ConfigObj module. It doesn't handle circular referencse. Even better, it has 3 native representations; repr(a).encode('zlib'), repr(a), pprint.pprint(a); each offering a different amount of user readability. I digress. I believe the biggest problem with the proposal, as specified, is that changing the semantics of __getstate__ and __setstate__ is a bad idea. Add a new pair of methods and ask the twisted people what they think. My only criticism will then be the strawman repr/unrepr. - Josiah