BAW> Maybe we should lock bsddbmodule down to Berkeley 1.85 and then
Please don't do that. That creates two problems. On the one hand it will
break code for people like me who successfully use db2 or db3. On the other
hand, you will force all users of dbhash and bsddb and all users of anydbm
who have bsddb installed to use the provably broken hash file
implementation. If you want to lock bsddb down to the 1.85 API, force it to
only build with db2 or db3 and reject attempts to compile/link it with db1.
BAW> pull pybsddb (which exports as module bsddb3) for Berkeley 3.3.11.
BAW> If there's a clamor for it, I suppose we could fake a bsddb2 and
BAW> bsddb4 for those major versions of Berkeley.
Why the proliferation? I can see the argument for incorporating pybsddb
into the core because it offers greater functionality, but why incorporate
version names into module names that track releases? If Sleepycat's
behavior in the past is any indication of its behavior in the future, they
will change both the API and file formats in every release and give you
various, incompatible tools with which to migrate each time.
Skip
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