On 1/26/07, tomer filiba <tomerfiliba@gmail.com> wrote:
This proposal does not state what "atomic" means -- this is open to the decision of the class. The only restriction imposed is, collections of any kind must be simplified as tuples.
It is worth stating the minimum that a compliant serializer must be able to treat atomically. For instance, is it always sufficient to reduce state to instances of (builtin, not subclasses of) string, tuple, float, or int?
Simplification Protocol ======================= This proposal introduces two new special methods:
def __simplify__(self): return type, state
If I understand correctly, this returns the actual type object, rather than its name, or the source code to rebuild that type. Are there any requirements on what sort of type objects the serializer must be able to support?
I do not see a need for a convenience routine such as simplify(obj) <--> obj.__simplify__(), since this API is not designed for everyday usage. This is the case with __reduce__ today.
reduce is nasty for beginners. In fairness, I think much of the problem is that reduce and __reduce__ (as well as __reduce_ex__) both exist, but are unrelated. So adding simplify probably isn't required, but reserving the name might be.
Note that this proposal does not define how atomic objects are to be converted to strings, or how a 'recursive simplifier' should work. These issues are to be resolved by the implementation of the serializer.
Is there some minimum requirement on is-stability? For example, would the following relationships be preserved after deserialization? >>> a1=object() >>> a2=a1 >>> b=object() >>> a1 is a2 True >>> a1 is b False -jJ