Primarily, our Python objects exist in volatile computer memory. The upper bound on the life of an object is the duration of the Python process. This lifetime is further constrained by objects only lasting as long there are references to them. If we want an object with a longer duration, we need to make it persistent. If we want to extract the state of an object from one process and provide this state information to another process, the same serialization techniques for persistence can be used for the transfer of object state.

Most operating systems offer persistent storage in the form of a filesystem. This can include disk drives, flash drives, or other forms of non-volatile storage. Persisting the bytes from memory to the filesystem turns out to be surprisingly difficult.

The complexity arises because our in-memory Python objects have references to other objects. An object refers to its class. The class refers to any base classes. The object might be a container and refer to other objects. The in-memory version of an object is a web of references and relationships. The references are generally based on the locations in memory, which are not fixed: the relationships would be broken by trying to simply dump and restore memory bytes.

The web of references surrounding an object contains other objects that are largely static. Class definitions, for example, change very slowly compared to instance variables within an object. Python gives us a formal distinction between the instance variables of an object and other methods defined in the class. Consequently, serialization techniques focus on persisting the dynamic state of an object based on its instance variables.

We don't actually have to do anything extra to persist class definitions; we already have a very simple method for handling classes. Class definitions exist primarily as source code. The class definition in the volatile memory is rebuilt from the source (or the byte-code version of the source) every time it's needed. If we need to exchange a class definition, we exchange Python modules or packages.

Let's take a look at common Python terminology in the next section.