summaryrefslogtreecommitdiffstats
path: root/Lib/whichdb.py
Commit message (Collapse)AuthorAgeFilesLines
* Create the dbm package from PEP 3108. #2881.Georg Brandl2008-05-261-118/+0
|
* Remove RISCOS supportSkip Montanaro2007-08-161-6/+6
|
* Make gdbm and dumbdbm use byte strings. Updated their tests.Guido van Rossum2007-05-231-6/+7
|
* Fix most trivially-findable print statements.Guido van Rossum2007-02-091-1/+1
| | | | | | | | | There's one major and one minor category still unfixed: doctests are the major category (and I hope to be able to augment the refactoring tool to refactor bona fide doctests soon); other code generating print statements in strings is the minor category. (Oh, and I don't know if the compiler package works.)
* Replace list of constants with tuples of constants.Raymond Hettinger2005-02-061-1/+1
|
* SF patch #1038388: __main__ for whichdb.pyRaymond Hettinger2004-10-201-0/+5
| | | | (Contributed by Oleg Broytmann.)
* Fix a bunch of typos in documentation, docstrings and comments.Walter Dörwald2003-10-201-1/+1
| | | | (From SF patch #810751)
* patch #766650 - whichdb not identifying dbm DBs when dbm linked with gdbmAndrew MacIntyre2003-07-111-2/+5
| | | | | | | | | | | | | At this point, the problem appears particular to the OS/2 EMX port of gdbm (which is at v1.7.3) - this combination produces a .pag file but no .dir file. A more sophisticated patch which checks magic numbers when dbm.library indicates that dbm is linked to gdbm, and there is no .dir file, is still attached to the above patch entry for reconsideration after 2.3 is released. This checkin applies a workaround specific to the known failure case.
* Patch #755087: Deal with emptied dumbdbm files correctly.Martin v. Löwis2003-06-211-3/+3
|
* Treat empty dat/dir pairs as dumbdbm. Fixes #744687.Martin v. Löwis2003-06-141-3/+7
|
* detect old version 2 hash files and return "bsddb185" as the appropriateSkip Montanaro2003-05-061-3/+4
| | | | module to load them
* catch the situation where Berkeley DB is used to emulate dbm(3) librarySkip Montanaro2002-08-021-3/+24
| | | | | functions. In this case, calling dbm.open("foo", "c") actually creates a file named "foo.db".
* SF patch #474590 -- RISC OS supportGuido van Rossum2001-10-241-9/+4
|
* Whitespace normalization.Tim Peters2001-03-161-1/+1
|
* RISCOS changes by dschwertberger.Guido van Rossum2001-03-021-4/+11
|
* move import into function to avoid having to add an __all__ list...Skip Montanaro2001-03-011-2/+2
|
* Add missing 'try:'. Patch by Rob W. W. Hooft, #101071 (closed.)Thomas Wouters2000-08-041-0/+1
|
* Added support to recognize Python's internal "dumbdbm" database.Moshe Zadka2000-07-291-0/+12
| | | | This closes bug 200 on Jitterbug.
* Untabify to pass the -tt test.Fred Drake2000-02-101-1/+1
|
* Skip Montanaro:Guido van Rossum1999-06-081-2/+13
| | | | | | | | | I guess in 1.5.2 a new module, whichdb, was added that attempts to divine the nature of a database file. This module doesn't know anything about Berkeley DB v2 files. In v2, Sleepycat added a 12-byte null pad in front of the old magic numbers (at least for hash and btree files). I've been using v2 for awhile and upgrading to 1.5.2 broke all my anydbm.open calls. I believe the following patch corrects the problem.
* Support byte-swapped dbhash (bsddb) files. Found by Ben Sayer.Guido van Rossum1998-04-281-1/+1
|
* Mass check-in after untabifying all files that need it.Guido van Rossum1998-03-261-13/+13
|
* Use new struct which supports standardized sizesGuido van Rossum1997-01-111-5/+2
|
* Function to guess which db package created a database.Guido van Rossum1996-07-301-0/+60