On 26.06.2013 04:10, Larry Hastings wrote:
Everything I read in this thread says that 2.7 only gets bug fixes, and even at that it has to be a pretty bad bug. (Benjamin: "If it's been broken for all of the 2.x series, it probably doesn't need to be fixed now.") I don't see even mild dissent; the replies have been strongly unanimous.
Less than a day ago Benjamin relented on reverting Raymond's deque-block-size changeset. He has since reapplied the change. Therefore as of now this change will go into 2.7.6. Although it looks like a fine idea, AFAICT this is not a bug fix--unless a longstanding performance regression can be considered a bug fix. So I don't understand why this change was reapplied.
I'm not questioning the decision--I'm asking, what is the heuristic I can apply in the future to predict whether or not a change will be accepted into the 2.7 branch. My current heuristic ("only bad bug fixes") seems to be on the fritz.
Let's not forget that Python 2.7 is the currently most used Python version there is. It's being used in production and many people rely on it.
I think that bug fixes (including fixes for performance regressions) should continue to go into the 2.7 branch, as well as fixes that allow compiling Python 2.7 on more recent platforms.
The current schedule is to provide bug fix releases at least until 2015:
Given that the transition to Python 3 is just starting to pick up speed this year, we may have to revisit the 2015 end-of-support next year.