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
Right now we support
ndbmandgnu.dbmwhich might or might not be part of a given build. The fallback is the super slowdumbdbm. Not the sqlite3 is part of the standard build, we can do better.The module docstring says:
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
sqlite3module, or there can be a C extension that calls the Sqlite3 C API directly.This would automatically be available to the
shelvemodule, giving us a high quality, persistent key-value store.Linked PRs