On Wed, Sep 3, 2008 at 4:41 PM, Raymond Hettinger <python@rcn.com> wrote:
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.
Perhaps, but that could be said about almost any module that has been removed through the stdlib reorg.
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.
We don't have to remove anything that has gone through the stdlib reorg, so that is not a solid argument.
So why do it hastily at the last minute and without some discussion on comp.lang.python at least.
It isn't being done "hastily"; this has been planned for a while. People have just been too busy to get around to it. And we are not changing any semantics or removing something from the language which is what I view as what you don't change in an rc. So this might come down to a different opinion of what one can do during an rc.
If it were any other release, we would have disciplined ourselves to deprecate first and remove a generation or two later.
We are deprecating first in 2.6.
Also, the reason for removal may yet disappear if jcrea steps in an continues to make updates.
OK, but none of his changes have received a code review, so if we are going to go down the whole "disciplined" route about it being an rc then we should back out all of Jesus' changes for both 2.6 and 3.0, which puts us back to the same instability issues.
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.
Well, it was in the PEP before beta2 even went out the door. -Brett