[Python-Dev] [issue3769] Deprecate bsddb for removal in 3.0

[Jesus Cea]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nick Coghlan wrote:
> While that will still be visible to some degree due to the presence of
> the 2.x version of the bsddb code in Python 2.6, I don't think it will
> be quite the same as it would have been with the 3.x version also being
> readily available as part of the standard 3.0 install.

Since 2.6 intention seems to mark this module as deprecated, I guess 2.x
bsddb presence in stock python will finish in 2.7. Moreover, I'm working
just now improving 2.x/3.x conversion code in pybsddb. I think this code
will be available in bsddb 4.7.4, and it will not be integrated in
Python 2.6 (that will include 4.7.3.minor releases, if we keep the
criteria of "only stability and security fixes in 2.6.x").

If the idea is to keep bsddb alive in 2.x, I don't see the point of not
keeping the 3.0 version, because the issues used to justify the removal
persist: I'm the only maintainer, little code review, buildbot issues, etc.

(I would like a comprehensive list, to be able to improve those
deficiencies).

In fact, if we keep bsddb in 2.x, the pressure to keep it in 3.x will be
higher.

> Regardless, given that the removal of bsddb from the 3.0 branch is now a
> done deal in svn, I suggest that all we can do is monitor how much

Any version control system can revert that with a single command :).

All I can say is that current bsddb code (in my personal repository)
passes all tests in current compiled python3.0 binary, called with the
"-bb" parameter flag (the "-bb" flag was something I learned yesterday).

> but in the meantime there *are* real benefits to
> decoupling the maintenance cycles (those wanting to get the most out of
> Jesus's ongoing work in exposing more of the bsddb API are probably
> going to want to be using the external pybsddb releases anyway rather
> than waiting however many months it ends up being until we get to 2.7/3.1).

The cycles are actually decoupled since I toke over the bsddb
maintenance (I've released a new version per month). So the release
cycles are not an issue.

The main issue here is 3.0 support, that I worked over the last couple
of months. It is done now. It couldn't be done faster because I was
learning 3.0 internals on-the-fly (there are NO docs about C module
migration; my experience there could be valuable) and 3.0 was a moving
target (still is). For example, when I left to summer holiday bsddb
worked flawless in Python 3.0b2. It failed in 3.0b3 because threading
renames done in python 3.0.

So, Python 3.0 is not waiting for bsddb to be ready, because it already
is (since yesterday). And future Python releases won't suffer because we
won't have any other major architectural reengineering of Python in a
long long time (I hope!).

That is, future Python releases would take whatever bsddb is available
at that time. No wait. No dependent release cycles. With my current
release schema of "a release per month", I can track python evolution
with little effort. For example, Python 2.5 to 2.6 was pretty painless,
even with the "PyBytes_*" ugliness.

> As far as the corporate scenarios go: if a corporate environment is *so*
> screwed up as to simultaneously permit a migration from Python 2.x to
> 3.0 of an internal project that relies on bsddb, while at the same time
> banning those performing the migration from installing the 3.0
> compatible version of pybsddb, then they have much bigger problems than
> which modules and packages we are choosing to include in the standard
> library.

Agreed. I was thinking about bsddb removal in 2.7.

- --
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSMAEnplgi5GaxT1NAQIrKgP/YAp45HUSG8Q+M355LTVqlcLMLkycpooc
fflW0MlQ3zZV307VBUbGo9urkS6h1pYhYByivApylhVqj8D4x8OEmMZk0lX8cegG
LYSBzs/sBeyxWWva6r5D9/4DsgJe9ZHqaBLMpy6ipPNVtUbMS61VTNovb3wP+f72
EnSIf9k/glM=
=QxRo
-----END PGP SIGNATURE-----