On Friday 18 July 2008 07:57:01 am Josiah Carlson wrote: > On Fri, Jul 18, 2008 at 7:21 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > On Thu, Jul 17, 2008 at 10:43 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > >> On Thu, Jul 17, 2008 at 7:37 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > >>> On Thu, Jul 17, 2008 at 7:30 PM, Fred Drake <[EMAIL PROTECTED]> wrote: > >>>> On Jul 17, 2008, at 7:27 PM, Martin v. Löwis wrote: > >>>>> bsddb is in a very bad shape, as the 2.6 code hasn't been merged into > >>>>> 3k. I somewhat doubt that this gets resolved before the release, so > >>>>> bsddb users might need to skip 3.0. > >>>> > >>>> In fact, bsddb as packages in core Python has rarely been in good > >>>> shape. > >>>> > >>>> Has anyone actually considered that bsddb might do better if > >>>> maintained strictly as an external package? That would make it easier > >>>> for the any maintainers to release updates, and removes a source of > >>>> frustration for users who either don't need it or would rather wait > >>>> for a happier version. > >>>> > >>>> I think this is worth considering. I vaguely recall that the bsddb > >>>> module was maintained before it was incorporated into the core Python > >>>> release. > >>> > >>> +1. In my recollection maintaining bsddb has been nothing but trouble > >>> right from the start when we were all sitting together at "Zope Corp > >>> North" in a rented office in McLean... We can remove it from 3.0. We > >>> can't really remove it from 2.6, but we can certainly start > >>> end-of-lifing it in 2.6. > >> > >> Unless I hear otherwise, I will add it to PEP 3108. > > > > Please do! > > 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 :/. > > Just an idea. > > - Josiah > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/charleshixsn%40earthlink. >net
Were I to vote for "something" it would be a B+Tree in collections. One that didn't impose a requirement that the key be a string (and not, e.g., an integer or a float). OTOH, I don't care enough to build it. (I've proven this to myself repeatedly, as I've started to create such a thing, and then kludged a different solution.) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
