[Python-ideas] simplification pep-like thing

[Jim Jewett]

On 1/26/07, tomer filiba <tomerfiliba at 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