Serialization

Notes on our existing serialization protocols: pickle and script_repr. The plan is to turn this page into official documentation and move out of wiki.

In overview, pickle's for serializing all state completely, while script_repr is for generating human-readable, runnable code (via eval) that recreates important state but does not try to be complete.

pickle

• python only
• not human readable

Pickling is used to save the state of a parameterized object completely (including non-parameter attributes) for (not too distant) future reloading in python, to use again as if you'd never serialized/deserialized the object at all. The object's class definition must be available during unpickling.

Furthermore, pickle will handle a whole graph of instances - the same instance occurring multiple times will only be pickled once.

script_repr

• python only
• human readable

script_repr's purpose is to generate runnable python code that can be used to recreate a parameterized object as if you were newly instantiating it from the class definition with the parameter values it had when you serialized it (no other attributes included). The class definition must be available when running the code generated by script_repr.

Example for some.module containing

class A(Parameterized):
    a = param.Number(default=1)
    b = param.Number(default=1)

For a=A(b=2), the serialization would be

import some.module
some.module.A(b=2)

For a graph of instances, the same instance occurring multiple times will result in multiple instances.

Controlling serialization/deserialization

To control serialization/deserialization with pickle, parameterized classes may define __getstate__/__setstate__ methods. (There are also other ways to control pickling, including a registry of handlers that can control pickling - usually used for other people's classes.)

To control serialization with script_repr, parameterized classes may have __repr__. And again we use a registry of handlers, script_repr_reg, for other people's classes.