Right now we support ndbm and gnu.dbm which might or might not be part of a given build. The fallback is the super slow dumbdbm. Not the sqlite3 is part of the standard build, we can do better.

The module docstring says:

Future versions may change the order in which implementations are
tested for existence, and add interfaces to other dbm-like
implementations.

The future is now. Let's provide a fast, stable, robust, always available alternative.

This can be done will pure python calls to the existing sqlite3 module, or there can be a C extension that calls the Sqlite3 C API directly.

This would automatically be available to the shelve module, giving us a high quality, persistent key-value store.

Linked PRs

• gh-100414: Add SQLite backend to dbm #114481
• gh-100414: Make dbm.sqlite3 the preferred dbm backend #115447
• gh-100414: Skip test_dbm_sqlite3 if sqlite3 is unavailable #115448
• gh-100414: Skip test_dbm_sqlite3 if sqlite3 is unavailable #115449