-----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@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@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-----