[Python-Dev] [Python-3000] No beta2 tonight
charleshixsn at earthlink.net
Fri Jul 18 21:35:46 CEST 2008
On Friday 18 July 2008 07:57:01 am Josiah Carlson wrote:
> On Fri, Jul 18, 2008 at 7:21 AM, Guido van Rossum <guido at python.org> wrote:
> > On Thu, Jul 17, 2008 at 10:43 PM, Brett Cannon <brett at python.org> wrote:
> >> On Thu, Jul 17, 2008 at 7:37 PM, Guido van Rossum <guido at python.org>
> >>> On Thu, Jul 17, 2008 at 7:30 PM, Fred Drake <fdrake at acm.org> 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 at python.org
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
More information about the Python-Dev