1998-08-10 16:42:37 -03:00
|
|
|
\section{\module{shelve} ---
|
|
|
|
Python object persistency.}
|
1998-07-23 14:59:49 -03:00
|
|
|
\declaremodule{standard}{shelve}
|
|
|
|
|
|
|
|
\modulesynopsis{Python object persistency.}
|
|
|
|
|
1995-02-15 11:53:08 -04:00
|
|
|
|
|
|
|
A ``shelf'' is a persistent, dictionary-like object. The difference
|
|
|
|
with ``dbm'' databases is that the values (not the keys!) in a shelf
|
|
|
|
can be essentially arbitrary Python objects --- anything that the
|
|
|
|
\code{pickle} module can handle. This includes most class instances,
|
|
|
|
recursive data types, and objects containing lots of shared
|
|
|
|
sub-objects. The keys are ordinary strings.
|
1997-12-15 17:59:33 -04:00
|
|
|
\refstmodindex{pickle}
|
1995-02-15 11:53:08 -04:00
|
|
|
|
|
|
|
To summarize the interface (\code{key} is a string, \code{data} is an
|
|
|
|
arbitrary object):
|
|
|
|
|
1998-02-13 02:58:54 -04:00
|
|
|
\begin{verbatim}
|
1995-02-15 11:53:08 -04:00
|
|
|
import shelve
|
|
|
|
|
|
|
|
d = shelve.open(filename) # open, with (g)dbm filename -- no suffix
|
|
|
|
|
|
|
|
d[key] = data # store data at key (overwrites old data if
|
|
|
|
# using an existing key)
|
|
|
|
data = d[key] # retrieve data at key (raise KeyError if no
|
|
|
|
# such key)
|
|
|
|
del d[key] # delete data stored at key (raises KeyError
|
|
|
|
# if no such key)
|
|
|
|
flag = d.has_key(key) # true if the key exists
|
|
|
|
list = d.keys() # a list of all existing keys (slow!)
|
|
|
|
|
|
|
|
d.close() # close it
|
1998-02-13 02:58:54 -04:00
|
|
|
\end{verbatim}
|
1997-07-17 13:34:52 -03:00
|
|
|
%
|
1995-02-16 12:29:01 -04:00
|
|
|
Restrictions:
|
|
|
|
|
|
|
|
\begin{itemize}
|
|
|
|
|
|
|
|
\item
|
1997-12-15 17:59:33 -04:00
|
|
|
The choice of which database package will be used (e.g. \code{dbm} or
|
|
|
|
\code{gdbm})
|
1995-02-16 12:29:01 -04:00
|
|
|
depends on which interface is available. Therefore it isn't safe to
|
1997-12-15 17:59:33 -04:00
|
|
|
open the database directly using \code{dbm}. The database is also
|
|
|
|
(unfortunately) subject to the limitations of \code{dbm}, if it is used ---
|
1995-02-16 12:29:01 -04:00
|
|
|
this means that (the pickled representation of) the objects stored in
|
|
|
|
the database should be fairly small, and in rare cases key collisions
|
|
|
|
may cause the database to refuse updates.
|
1997-12-15 17:59:33 -04:00
|
|
|
\refbimodindex{dbm}
|
|
|
|
\refbimodindex{gdbm}
|
1995-02-16 12:29:01 -04:00
|
|
|
|
|
|
|
\item
|
1995-02-15 11:53:08 -04:00
|
|
|
Dependent on the implementation, closing a persistent dictionary may
|
|
|
|
or may not be necessary to flush changes to disk.
|
|
|
|
|
1995-02-16 12:29:01 -04:00
|
|
|
\item
|
1997-12-15 17:59:33 -04:00
|
|
|
The \code{shelve} module does not support \emph{concurrent} read/write
|
1995-03-17 12:07:09 -04:00
|
|
|
access to shelved objects. (Multiple simultaneous read accesses are
|
|
|
|
safe.) When a program has a shelf open for writing, no other program
|
|
|
|
should have it open for reading or writing. \UNIX{} file locking can
|
|
|
|
be used to solve this, but this differs across \UNIX{} versions and
|
|
|
|
requires knowledge about the database implementation used.
|
1995-02-16 12:29:01 -04:00
|
|
|
|
|
|
|
\end{itemize}
|
1998-08-24 15:46:14 -03:00
|
|
|
|
|
|
|
|
|
|
|
\begin{seealso}
|
|
|
|
\seemodule{pickle}{Object serialization used by \module{shelve}.}
|
|
|
|
\seemodule{cPickle}{High-performance version of \module{pickle}.}
|
|
|
|
\end{seealso}
|