Mark Lutz wrote:
I read several different issues into your message: * standards doc * speed of change * deprecations * backwards incompatibilities Standards doc: we have one but it is out of date. I think that it would be great if someone has the bandwidth to improve it but I'm not going to push Guido very hard to do that because there's a lot of more high priority stuff I'd like to see him work on. Speed of change: it wasn't really so radical if you think in terms of how long these suggestions have been "queued". I would not like it if Python kept up the same pace of language additions but I don't think that's going to happen. Deprecation: deprecations are a good thing. They are the only way that Python will ever drop old features. If Python never drops old features then it can only ever grow. If it only ever grows then it will only become more and more difficult to learn. I don't think I have to justify the importance of learnability... Backwards Incompatibilities: I feel strongly that we need to be more conservative about code breakage. Python 2 was not backwards compatible enough. It should have deprecated the code and used warnings instead. Here's my suggested solution for the future: http://python.sourceforge.net/peps/pep-0005.html
A prime example: the string module, used in almost every Python program ever written by the half-million Python users out there, has suddenly been marked as deprecated. I expect that it won't really go away, but has anyone considered the impact of even the suggestion of its deprecation on Python's acceptance?
Sometimes we make mistakes. Making mistakes is part of learning. String functions should have been methods. We had to correct that mistake. What other mechanism do we have for correcting mistakes other than deprecation? Paul Prescod