Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit 4179691

Browse files
committed
Fix a few markup nits, improve some index entries.
1 parent 7d80779 commit 4179691

1 file changed

Lines changed: 41 additions & 38 deletions

File tree

Doc/lib/libpickle.tex

Lines changed: 41 additions & 38 deletions
Original file line numberDiff line numberDiff line change
@@ -12,29 +12,30 @@ \section{\module{pickle} ---
1212
\indexii{pickling}{objects}
1313

1414

15-
The \module{pickle} module implements a basic but powerful algorithm for
16-
``pickling'' (a.k.a.\ serializing, marshalling or flattening) nearly
17-
arbitrary Python objects. This is the act of converting objects to a
18-
stream of bytes (and back: ``unpickling'').
19-
This is a more primitive notion than
20-
persistency --- although \module{pickle} reads and writes file objects,
21-
it does not handle the issue of naming persistent objects, nor the
22-
(even more complicated) area of concurrent access to persistent
23-
objects. The \module{pickle} module can transform a complex object into
24-
a byte stream and it can transform the byte stream into an object with
25-
the same internal structure. The most obvious thing to do with these
26-
byte streams is to write them onto a file, but it is also conceivable
27-
to send them across a network or store them in a database. The module
15+
The \module{pickle} module implements a basic but powerful algorithm
16+
for ``pickling'' (a.k.a.\ serializing, marshalling or flattening)
17+
nearly arbitrary Python objects. This is the act of converting
18+
objects to a stream of bytes (and back: ``unpickling''). This is a
19+
more primitive notion than persistency --- although \module{pickle}
20+
reads and writes file objects, it does not handle the issue of naming
21+
persistent objects, nor the (even more complicated) area of concurrent
22+
access to persistent objects. The \module{pickle} module can
23+
transform a complex object into a byte stream and it can transform the
24+
byte stream into an object with the same internal structure. The most
25+
obvious thing to do with these byte streams is to write them onto a
26+
file, but it is also conceivable to send them across a network or
27+
store them in a database. The module
2828
\refmodule{shelve}\refstmodindex{shelve} provides a simple interface
2929
to pickle and unpickle objects on DBM-style database files.
3030

3131

3232
\strong{Note:} The \module{pickle} module is rather slow. A
3333
reimplementation of the same algorithm in C, which is up to 1000 times
34-
faster, is available as the \refmodule{cPickle}\refbimodindex{cPickle}
35-
module. This has the same interface except that \code{Pickler} and
36-
\code{Unpickler} are factory functions, not classes (so they cannot be
37-
used as base classes for inheritance).
34+
faster, is available as the
35+
\refmodule{cPickle}\refbimodindex{cPickle} module. This has the same
36+
interface except that \class{Pickler} and \class{Unpickler} are
37+
factory functions, not classes (so they cannot be used as base classes
38+
for inheritance).
3839

3940
Unlike the built-in module \refmodule{marshal}\refbimodindex{marshal},
4041
\module{pickle} handles the following correctly:
@@ -72,12 +73,11 @@ \section{\module{pickle} ---
7273
the default may change to binary.
7374

7475
The \module{pickle} module doesn't handle code objects, which the
75-
\refmodule{marshal} module does. I suppose \module{pickle} could, and maybe
76-
it should, but there's probably no great need for it right now (as
77-
long as \refmodule{marshal} continues to be used for reading and writing
78-
code objects), and at least this avoids the possibility of smuggling
79-
Trojan horses into a program.
80-
\refbimodindex{marshal}
76+
\refmodule{marshal}\refbimodindex{marshal} module does. I suppose
77+
\module{pickle} could, and maybe it should, but there's probably no
78+
great need for it right now (as long as \refmodule{marshal} continues
79+
to be used for reading and writing code objects), and at least this
80+
avoids the possibility of smuggling Trojan horses into a program.
8181

8282
For the benefit of persistency modules written using \module{pickle}, it
8383
supports the notion of a reference to an object outside the pickled
@@ -109,10 +109,15 @@ \section{\module{pickle} ---
109109
passed to the class constructor (\method{__init__()}). This method is
110110
called at pickle time; the tuple it returns is incorporated in the
111111
pickle for the instance.
112-
\ttindex{__getinitargs__()}
113-
\ttindex{__init__()}
114-
115-
Classes can further influence how their instances are pickled --- if the class
112+
\withsubitem{(copy protocol)}{\ttindex{__getinitargs__()}}
113+
\withsubitem{(instance constructor)}{\ttindex{__init__()}}
114+
115+
Classes can further influence how their instances are pickled --- if
116+
the class
117+
\withsubitem{(copy protocol)}{
118+
\ttindex{__getstate__()}\ttindex{__setstate__()}}
119+
\withsubitem{(instance attribute)}{
120+
\ttindex{__dict__}}
116121
defines the method \method{__getstate__()}, it is called and the return
117122
state is pickled as the contents for the instance, and if the class
118123
defines the method \method{__setstate__()}, it is called with the
@@ -126,9 +131,6 @@ \section{\module{pickle} ---
126131
--- these methods can do what they want.) This protocol is also used
127132
by the shallow and deep copying operations defined in the
128133
\refmodule{copy}\refstmodindex{copy} module.
129-
\ttindex{__getstate__()}
130-
\ttindex{__setstate__()}
131-
\ttindex{__dict__}
132134

133135
Note that when class instances are pickled, their class's code and
134136
data are not pickled along with them. Only the instance data are
@@ -175,12 +177,12 @@ \section{\module{pickle} ---
175177
\end{verbatim}
176178

177179
The \class{Pickler} class only calls the method \code{f.write()} with a
180+
\withsubitem{(class in pickle)}{
181+
\ttindex{Unpickler}\ttindex{Pickler}}
178182
string argument. The \class{Unpickler} calls the methods \code{f.read()}
179183
(with an integer argument) and \code{f.readline()} (without argument),
180184
both returning a string. It is explicitly allowed to pass non-file
181185
objects here, as long as they have the right methods.
182-
\ttindex{Unpickler}
183-
\ttindex{Pickler}
184186

185187
The constructor for the \class{Pickler} class has an optional second
186188
argument, \var{bin}. If this is present and nonzero, the binary
@@ -190,6 +192,7 @@ \section{\module{pickle} ---
190192
between binary and text pickle formats; it accepts either format.
191193

192194
The following types can be pickled:
195+
193196
\begin{itemize}
194197

195198
\item \code{None}
@@ -257,7 +260,7 @@ \section{\module{pickle} ---
257260

258261
\begin{excdesc}{PicklingError}
259262
This exception is raised when an unpicklable object is passed to
260-
\code{Pickler.dump()}.
263+
\method{Pickler.dump()}.
261264
\end{excdesc}
262265

263266

@@ -283,11 +286,11 @@ \section{\module{cPickle} ---
283286

284287

285288
The \module{cPickle} module provides a similar interface and identical
286-
functionality as the \refmodule{pickle} module, but can be up to 1000
287-
times faster since it is implemented in C. The only other
288-
important difference to note is that \function{Pickler()} and
289-
\function{Unpickler()} are functions and not classes, and so cannot be
290-
subclassed. This should not be an issue in most cases.
289+
functionality as the \refmodule{pickle}\refstmodindex{pickle} module,
290+
but can be up to 1000 times faster since it is implemented in C. The
291+
only other important difference to note is that \function{Pickler()}
292+
and \function{Unpickler()} are functions and not classes, and so
293+
cannot be subclassed. This should not be an issue in most cases.
291294

292295
The format of the pickle data is identical to that produced using the
293296
\refmodule{pickle} module, so it is possible to use \refmodule{pickle} and

0 commit comments

Comments
 (0)