That is not correct; dbm.open(path) calls dbm.whichdb(path) to determine which backend to use. You’d still be able to open a database created with dbm.gnu, even if the default changes. The default is only used when you’re creating a new database (flag="c" or flag="n").
The current scenario is:
- Windows: only dbm.dumb is available; you can create a database using
dbm.open(path, "n")and transfer the database file to any other platform and open it there - macOS (python.org installer): dbm.dumb and dbm.ndbm are available; you can create a database using
dbm.open(path, "n"); ndbm will take precedence over dumbdbm; you can transfser the database til to another macOS or possibly a Linux system (depending on which backends are available) - Linux: dbm.dumb is available, possibly dbm.ndbm, and likely dbm.gnu (gdbm); you can create a database using
dbm.open(path, "n"); gdbm will likely be chosen, so you cannot easily transfer the database to another platform.
If dbm.sqlite3 is made available, but not made the default, this will be the user experience:
- Windows: create a database using
dbm.open(path, "n"); the sqlite3 backend is selected; you can transfer your database to any other system => increased user experience - macOS: create a database using
dbm.open(path, "n"); the ndbm backend is selected; no change in user experience - Linux: create a database using
dbm.open(path, "n"); either gdbm or ndbm is selected; no change in user experience
If dbm.sqlite3 is made available and made the default, this will be the user experience:
- Any platform: create a database using
dbm.open(path, "n"); transfer the database file to any other system and continue hacking on it there => increase in user experience on all platforms
Regarding performance; as Greg says, if people are looking for a fine-tuned database, they’ll probably be using a real database where you can fine-tune it for whatever requirements your application have.
(So I’m still +1 for making sqlite3 the default backend. Let’s provide a consistent user experience.)