
M.-A. Lemburg wrote:
Michael Foord wrote:
Backwards compatibility is a *big* problem for any major refactoring though.
Sigh.
*sigh* Don't you just love emails that start with a sigh. Anyway, yes. That is why I said it was a problem. Good grief. Michael
I sometimes get the feeling that people on this list don't know Python's history, how it was developed over the past decade and what our goals were.
Maintaining as much backwards compatibility as reasonably possible has always been a key goal and we've done a pretty good job at it (if I may say so).
As Py3k approached, it was deemed ok to break with the past and that was accepted by the core developers and the users. However, that time has past now and we're running in non-breaking mode again.
As we're starting to establish the Py3k branch as new stable Python branch, we're not suddenly going to change the goals we've established over the years in the Python 2.x branch.
Backwards compatibility is one of the key arguments for using Python as a development platform. As such it's not a problem, it's a feature of Python.
And while it may not mean much to developers who prefer to run bleeding edge code, it does mean a lot to the established Python user base.