On Fri, Jul 18, 2008 at 8:11 AM, Guido van Rossum <guido at python.org> wrote: > On Fri, Jul 18, 2008 at 7:57 AM, Josiah Carlson > <josiah.carlson at gmail.com> wrote: >> Invariably, when someone goes and removes a module, someone else is >> going to complain, "but I used feature X, not having feature X will >> break my code." We, as maintainers can then say, "if you cared, >> maintain it." But I'm not sure that is the greatest thing to tell >> people. I suspect that we may have to include some sort of >> "work-alike" for 2.7 and if not 3.0, 3.1 . If I were to vote for a >> work-alike, it would be based on sqlite. For one of the most common >> use-cases (bsddb.btree), simple sqlite code can be written to do the >> right thing. Recno is a little more tricky, but can also be done. >> The bsddb hash may not be possible, because sqlite doesn't support >> hashed indices :/. > > In my mind, BSDDB is pretty much the most heavy-weight extension we're > maintaining. I think it's an illusion that a sqlite-based look-alike > is going to fool anyone. The correct solution is to take support for > bsddb to a separate project where those who care about it can maintain > it together. That also makes it a lot easier to track the versions of > Berkeley DB as they come out. > > Of course, you're free to try writing the work-alike you're proposing. :-) It's entirely possible that I know very little about what was being made available via the bsddb module, but to match the API of what is included in the documentation (plus the dictionary interface that it supports) shouldn't be terribly difficult. Now, if there were *other* things that were undocumented, well, there's not much I can do about those. ;) - Josiah
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