described, and add a test for it.
2.5 bugfix candidate, maybe; arguably this patch changes the API of
dumbdbm and shouldn't be added in a point-release.
Related to SF patch 723231 (which pointed out the problem, but didn't
fix it, just shut up the warning msg -- which was pointing out a dead-
serious bug!).
Bugfix candidate.
databases are associated with corruption problems, so I studied this code
carefully and ran some brutal stress tests. I didn't find any bugs,
although it's unclear whether this code *intends* that __setitem__ can
leave the directory file out of synch with the data file (so
if a dumbdbm isn't properly closed, and the value of an existing key
was ever replaced, corruption is almost certain, where "corruption"
means the directory file is out of synch with the data file).
Added many comments and generally modernized the code. Examples of the
latter: we have better ways of reading a whole file line-by-line now;
eval() now tolerates a trailing newline; the %r format code can be used
to avoid explicit repr/backtick calls; and the code often broke tuples
into their components when it was clearer and faster to just leave them
as tuples.
Make dumbdbm merely "dumb", rather than "terminally broken". Without this
patch, it's almost impossible to use dumbdbm _without_ causing horrible
datalossage. With this patch, dumbdbm passes my own horrible torture test,
as well as the roundup test suite.
dumbdbm really could do with a smidgin of a rewrite or two, but that's not
suitable for the release21-maint branch.
There is a silly bug in the fall-back dumbdbm.py database package in
the Python 1.5.2 standard distro. This bug causes any changes to an
existing item to generate a new key, even when the key already
exists. After many updates, the .dir file used by dumbdbm grows to
a huge size, and can cause filesystem problems.
Andrew M. Kuchling
Skip Montanaro
Tim Peters
Raymond Hettinger
Neal Norwitz
Anthony Baxter
Fred Drake
Guido van Rossum
Martin v. Löwis