same number of calls to the \method{load()} method of the
corresponding \class{Unpickler} instance. If the same object is
pickled by multiple \method{dump()} calls, the \method{load()} will
-all yield references to the same object\footnote{\emph{Warning}: this
+all yield references to the same object.\footnote{\emph{Warning}: this
is intended for pickling multiple objects without intervening
modifications to the objects or their parts. If you modify an object
and then pickle it again using the same \class{Pickler} instance, the
\class{Unpickler} will return the old value, not the modified one.
There are two problems here: (1) detecting changes, and (2)
marshalling a minimal set of changes. Garbage Collection may also
-become a problem here.}.
+become a problem here.}
\class{Unpickler} objects are defined as:
is defined in. Neither the function's code, nor any of its function
attributes are pickled. Thus the defining module must be importable
in the unpickling environment, and the module must contain the named
-object, otherwise an exception will be raised\footnote{The exception
+object, otherwise an exception will be raised.\footnote{The exception
raised will likely be an \exception{ImportError} or an
-\exception{AttributeError} but it could be something else.}.
+\exception{AttributeError} but it could be something else.}
Similarly, classes are pickled by named reference, so the same
restrictions in the unpickling environment apply. Note that none of
Upon unpickling, if the class also defines the method
\method{__setstate__()}, it is called with the unpickled
-state\footnote{These methods can also be used to implement copying
-class instances.}. If there is no \method{__setstate__()} method, the
+state.\footnote{These methods can also be used to implement copying
+class instances.} If there is no \method{__setstate__()} method, the
pickled state must be a dictionary and its items are assigned to the
new instance's dictionary. If a class defines both
\method{__getstate__()} and \method{__setstate__()}, the state object
which is just an arbitrary string of printable \ASCII{} characters.
The resolution of such names is not defined by the \module{pickle}
module; it will delegate this resolution to user defined functions on
-the pickler and unpickler\footnote{The actual mechanism for
+the pickler and unpickler.\footnote{The actual mechanism for
associating these user defined functions is slightly different for
\module{pickle} and \module{cPickle}. The description given here
works the same for both implementations. Users of the \module{pickle}
module could also use subclassing to effect the same results,
overriding the \method{persistent_id()} and \method{persistent_load()}
-methods in the derived classes.}.
+methods in the derived classes.}
To define external persistent id resolution, you need to set the
\member{persistent_id} attribute of the pickler object and the
persistent id string will simply be appended to this list. This
functionality exists so that a pickle data stream can be ``sniffed''
for object references without actually instantiating all the objects
-in a pickle\footnote{We'll leave you with the image of Guido and Jim
-sitting around sniffing pickles in their living rooms.}. Setting
+in a pickle.\footnote{We'll leave you with the image of Guido and Jim
+sitting around sniffing pickles in their living rooms.} Setting
\member{persistent_load} to a list is usually used in conjunction with
the \method{noload()} method on the Unpickler.
mechanisms described here use internal attributes and methods, which
are subject to change in future versions of Python. We intend to
someday provide a common interface for controlling this behavior,
-which will work in either \module{pickle} or \module{cPickle}.}.
+which will work in either \module{pickle} or \module{cPickle}.}
In the \module{pickle} module, you need to derive a subclass from
\class{Unpickler}, overriding the \method{load_global()}
The pickle data stream produced by \module{pickle} and
\module{cPickle} are identical, so it is possible to use
\module{pickle} and \module{cPickle} interchangeably with existing
-pickles\footnote{Since the pickle data format is actually a tiny
+pickles.\footnote{Since the pickle data format is actually a tiny
stack-oriented programming language, and some freedom is taken in the
encodings of certain objects, it is possible that the two modules
produce different data streams for the same input objects. However it
is guaranteed that they will always be able to read each other's
-data streams.}.
+data streams.}
There are additional minor differences in API between \module{cPickle}
and \module{pickle}, however for most applications, they are
projects / python / commitdiff