It never fails (bsddb retirement in 2.3)

["Martin v. Löwis"]

Nick Vargish wrote:

> That's not the case at all. I don't think it's unreasonable of me to
> be perturbed that behavior that I relied upon in one version has
> changed, especially since one of the selling points of Python is that
> it traditionally is very backwards compatible.

You are certainly entitled to all kinds of feelings. However, I'd like
you to consider the bigger picture as well (bsddb is a standard package
only on minority platforms, like OSF/1, and it is a seriously broken 
library)

> When "import bsddb" gives a new set of features and requires a
> different library from the one that a previous version used quite
> happily, I consider that not being backwards compatible. 

Backwards compatibility has been taken into account when
making this change. The API of the new library is meant to be fully
backwards compatible to the old API. It requires a new library, yes,
but the module that wraps the old library has been preserved for
precisely the situation you are encountering.

> Discovering these issues is part of a beta test, is it not?

Perhaps. However, the case you encounter (Sleepycat is not installed,
the bsddb does not get built) is not surprising to the Python 
contributors. It may be surprising to users. As a free software project, 
  users interested in good support for their platform should then 
contribute to solve perceived problems on their platform.

I personally don't care so much about OSF/1 that I would work out a 
change here, especially since I believe it is not asked too much to 
install Sleepycat BSDDB on OSF/1. Python 2.3 will also have different
prerequisites for Tk, which I consider no problem, and has been 
requiring certain curses features for quite some time. There never was 
"high" backwards compatibility in terms of requirements towards the 
system - those change all the time. Compatibility on the API is more 
important, but still less important than compatibility in the language.

> Wouldn't it make sense, to some degree, to require the _new_
> functionality use a new module name, instead of changing the behavior
> of an existing one?

No. The old library has too many bugs.

> With that in mind, would I
> be better off using a different library, or abandoning this avenue for
> improving the performance of the programs in question? 

It would be best if you contributed a patch. This is what a beta is
for: to give users a chance to see changes before they happen, and
to suggest corrections.

Regards,
Martin