I think this should be deferred to Py3.1. This decision was not widely discussed and I think it likely that some users will be surprised and dismayed. The release candidate seems to be the wrong time to yank this out (in part because of the surprise factor) and in part because I think the change silently affects shelve performance so that the impact may be significantly negative but not readily apparent. We don't have to take this out. So why do it hastily at the last minute and without some discussion on comp.lang.python at least. If it were any other release, we would have disciplined ourselves to deprecate first and remove a generation or two later. Also, the reason for removal may yet disappear if jcrea steps in an continues to make updates. Also, the referenced note ( http://mail.python.org/pipermail/python-dev/2008-July/081379.html ) say to "start end-of-lifing it" which I took to mean deprecate rather than remove during a release candidate. Raymond ----- Original Message ----- From: "Benjamin Peterson" <report at bugs.python.org> To: <python-bugs-list at python.org> Sent: Wednesday, September 03, 2008 4:32 PM Subject: [issue3769] Deprecate bsddb for removal in 3.0 > > Benjamin Peterson <musiccomposition at gmail.com> added the comment: > > Also see this: > http://mail.python.org/pipermail/python-3000/2008-September/014712.html > > _______________________________________ > Python tracker <report at bugs.python.org> > <http://bugs.python.org/issue3769> > _______________________________________ > _______________________________________________ > Python-bugs-list mailing list > Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/python%40rcn.com >
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4