mirror of
				https://github.com/python/cpython.git
				synced 2025-11-04 03:44:55 +00:00 
			
		
		
		
	* \bcode, \ecode added everywhere
	* \label{module-foo} added everywhere
	* A few \seealso sections added.
	* Indentation fixed inside verbatim in lib*tex files
		
	
			
		
			
				
	
	
		
			60 lines
		
	
	
	
		
			2.1 KiB
		
	
	
	
		
			TeX
		
	
	
	
	
	
			
		
		
	
	
			60 lines
		
	
	
	
		
			2.1 KiB
		
	
	
	
		
			TeX
		
	
	
	
	
	
\section{Standard Module \sectcode{shelve}}
 | 
						|
\label{module-shelve}
 | 
						|
\stmodindex{shelve}
 | 
						|
\stmodindex{pickle}
 | 
						|
\bimodindex{dbm}
 | 
						|
\bimodindex{gdbm}
 | 
						|
 | 
						|
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.
 | 
						|
 | 
						|
To summarize the interface (\code{key} is a string, \code{data} is an
 | 
						|
arbitrary object):
 | 
						|
 | 
						|
\bcode\begin{verbatim}
 | 
						|
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
 | 
						|
\end{verbatim}\ecode
 | 
						|
%
 | 
						|
Restrictions:
 | 
						|
 | 
						|
\begin{itemize}
 | 
						|
 | 
						|
\item
 | 
						|
The choice of which database package will be used (e.g. dbm or gdbm)
 | 
						|
depends on which interface is available.  Therefore it isn't safe to
 | 
						|
open the database directly using dbm.  The database is also
 | 
						|
(unfortunately) subject to the limitations of dbm, if it is used ---
 | 
						|
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.
 | 
						|
 | 
						|
\item
 | 
						|
Dependent on the implementation, closing a persistent dictionary may
 | 
						|
or may not be necessary to flush changes to disk.
 | 
						|
 | 
						|
\item
 | 
						|
The \code{shelve} module does not support {\em concurrent} read/write
 | 
						|
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.
 | 
						|
 | 
						|
\end{itemize}
 |