Merged revisions 78141-78142 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r78141 | r.david.murray | 2010-02-10 20:38:42 -0500 (Wed, 10 Feb 2010) | 6 lines
Issue 5754: tweak shelve doc wording to make it clearer that even when
writeback=True values are written to the backing store when assigned to
the shelf. Add test to confirm that this happens. Doc patch and added
test by Robert Lehmann. I also fixed the cross references to the sync
and close methods.
........
r78142 | r.david.murray | 2010-02-10 20:56:42 -0500 (Wed, 10 Feb 2010) | 3 lines
Improve issue 7835 fix per MAL to handle the case that the
module dictionary has also been cleared.
........
diff --git a/Doc/library/shelve.rst b/Doc/library/shelve.rst
index 5d82dc4..c0bcb80 100644
--- a/Doc/library/shelve.rst
+++ b/Doc/library/shelve.rst
@@ -30,14 +30,15 @@
Because of Python semantics, a shelf cannot know when a mutable
persistent-dictionary entry is modified. By default modified objects are
- written only when assigned to the shelf (see :ref:`shelve-example`). If the
- optional *writeback* parameter is set to *True*, all entries accessed are
- cached in memory, and written back on :meth:`sync` and :meth:`close`; this
- can make it handier to mutate mutable entries in the persistent dictionary,
- but, if many entries are accessed, it can consume vast amounts of memory for
- the cache, and it can make the close operation very slow since all accessed
- entries are written back (there is no way to determine which accessed entries
- are mutable, nor which ones were actually mutated).
+ written *only* when assigned to the shelf (see :ref:`shelve-example`). If the
+ optional *writeback* parameter is set to *True*, all entries accessed are also
+ cached in memory, and written back on :meth:`~Shelf.sync` and
+ :meth:`~Shelf.close`; this can make it handier to mutate mutable entries in
+ the persistent dictionary, but, if many entries are accessed, it can consume
+ vast amounts of memory for the cache, and it can make the close operation
+ very slow since all accessed entries are written back (there is no way to
+ determine which accessed entries are mutable, nor which ones were actually
+ mutated).
.. note::