diff options
| -rw-r--r-- | Doc/lib/libshelve.tex | 15 | ||||
| -rw-r--r-- | Doc/libshelve.tex | 15 |
2 files changed, 16 insertions, 14 deletions
diff --git a/Doc/lib/libshelve.tex b/Doc/lib/libshelve.tex index 05b3a93..25ced0e 100644 --- a/Doc/lib/libshelve.tex +++ b/Doc/lib/libshelve.tex @@ -1,9 +1,6 @@ \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 @@ -11,6 +8,7 @@ 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. +\refstmodindex{pickle} To summarize the interface (\code{key} is a string, \code{data} is an arbitrary object): @@ -37,20 +35,23 @@ Restrictions: \begin{itemize} \item -The choice of which database package will be used (e.g. dbm or gdbm) +The choice of which database package will be used (e.g. \code{dbm} or +\code{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 --- +open the database directly using \code{dbm}. The database is also +(unfortunately) subject to the limitations of \code{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. +\refbimodindex{dbm} +\refbimodindex{gdbm} \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 +The \code{shelve} module does not support \emph{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 diff --git a/Doc/libshelve.tex b/Doc/libshelve.tex index 05b3a93..25ced0e 100644 --- a/Doc/libshelve.tex +++ b/Doc/libshelve.tex @@ -1,9 +1,6 @@ \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 @@ -11,6 +8,7 @@ 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. +\refstmodindex{pickle} To summarize the interface (\code{key} is a string, \code{data} is an arbitrary object): @@ -37,20 +35,23 @@ Restrictions: \begin{itemize} \item -The choice of which database package will be used (e.g. dbm or gdbm) +The choice of which database package will be used (e.g. \code{dbm} or +\code{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 --- +open the database directly using \code{dbm}. The database is also +(unfortunately) subject to the limitations of \code{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. +\refbimodindex{dbm} +\refbimodindex{gdbm} \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 +The \code{shelve} module does not support \emph{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 |