]> granicus.if.org Git - python/commit
There's a persistent rumor on the spambayes mailing list that dumbdbm
authorTim Peters <tim.peters@gmail.com>
Sat, 12 Jul 2003 20:11:25 +0000 (20:11 +0000)
committerTim Peters <tim.peters@gmail.com>
Sat, 12 Jul 2003 20:11:25 +0000 (20:11 +0000)
commit7dfd5701b20c3566166e148f77591a2912164221
tree7774ae8cbe923e55dd34964504ee324dc6590100
parent541342f82cf5819a9c6bbe80426d3074d5f229c3
There's a persistent rumor on the spambayes mailing list that dumbdbm
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.
Lib/dumbdbm.py