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.
erlend-aasland, tandav, presidento, edgarrmondragon and arseru
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4