It never fails (bsddb retirement in 2.3)

[Paul Rubin]

Skip Montanaro <skip at pobox.com> writes:
> I don't understand the bit about Sourceforge.  There is still a bsddb
> package delivered with Python 2.3.  API-wise it supports the old interface
> as well as supplying a much richer API than the earlier module.  The new
> package does require the newer version 3 or 4 DB from Sleepycat to build.
> If you still run version 1 or 2, simply tickle the appropriate lines in
> Modules/Setup to build the bsddb185 module.
> 
> Now would be a real good time to provide feedback on building the old
> bsddb185 module.  I don't think it's gotten much testing since retirement.
> There's plenty of time to tweak the build process.

What the heck is going on with this?  Please stop breaking things.
Include  bsdb185 in the default build.  If the new bsddb is really better,
then it's ok if "import bsddb" loads the new version but "import bsddb185"
should load the old version WITHOUT having to rebuild Python.

There are still an awful lot of systems running RedHat 7.x, which comes
with Python 1.5.2.  You cannot think of 1.5.2 as an obsolete version of
Python (in the sense that no one uses it any more).  1.5.2 comes with
bsddb 1.85 and ONLY 1.85.  

I wrote a script a while back that used bsddb (actually it used
"anydb" which loaded bsddb) and that script ran fine in production
from a crontab for over a year, happily accessing and updating a bsddb
1.85 database.  Then one day recently I found my mailbox full of error
messages.  It turns out that the system maintainer upgraded Python
from 1.5.2 to 2.2.x in order to install some new spam filter.  That
meant that "import anydb" suddenly started using bsddb 3.x which, I
can hardly believe it, is unable to read 1.85 databases without
running them through a conversion utility from Sleepycat.
Fortunately, I was able to get the maintainer to temporarily restore
Python 1.5.2, and my database is small enough that I can convert it to
the new format without (e.g.) running out of disk space, but it's just
another thing I have to get around to doing, and a PITA.  In other
kinds of situations, migrating the database could be a heck of a lot
more hassle, requiring service interruptions to more serious systems, etc.

Dan Bernstein at <http://cr.yp.to/immhf.html> has a relevant rant
about RFC822 email header format:

    A warning about evolution

    It's easy to add syntax to a protocol. First upgrade all the readers
    to understand the syntax; then the writers can safely start using it.

    For most protocols, it's just as easy to remove syntax. First upgrade
    all the writers to avoid the syntax; then the readers can safely stop
    supporting it.

    Mail is different. A mail message lasts forever. Millions of people
    have saved billions of messages; and they expect every new MUA to be
    able to parse every one of those messages. Tomorrow's readers have to
    be compatible with yesterday's writers.

Databases aren't as bad as email but the principle is the same.
Databases stay in operation for years and years.  The Python
maintainers should know from the many inquiries on this newsgroup
about Python web hosting that *users don't always get to choose what
version of python they run*.  They take what they can get.  And
rebuilding Python with a nonstandard configuration by "tickling
appropriate lines in Modules/Setup" is sometimes NOT AN OPTION for them.

So, please don't drop support for deprecated versions of bsddb, AND
don't require anyone to "tickle appropriate lines in Modules/Setup" to
make all the versions useable (at least by changing an import
statement in a script).  The person configuring and installing Python
is NOT necessarily the same as the person using it.