On Aug 31, 2005, at 5:00 PM, Robert Kern wrote:
IMO, if we are going to restrict Python 3000 enough to protect that "common subset," then there's not enough payoff to justify breaking *any* backwards compatibility. If my current codebase[1] isn't going to be supported in Python 3000, I'm going to want the Python developers to use that opportunity to the fullest advantage to make a better language.
I disagree fully. As a maintainer in the Twisted project I very much hope that it is possible to adapt the code such that it will work on Python 3 while still maintaining compatibility with Python 2.X. Otherwise, it will be impossible to make the transition to Python 3 without either maintaining two forks of the codebase (I doubt that'll happen) or abandoning all users still on Python 2. And that surely won't happen either, for a while. Maybe by the time Python 3.1 or 3.2 comes out it'll be possible to completely abandon Python 2. I'm perfectly happy to see backwards-incompatible changes in Python 3, as long as they do not make it completely impossible to write code that can run on both Python 3 and Python 2.X. This suggests a few things to me: a) new features should be added to the python 2.x series first wherever possible. b) 3.0 should by and large by simply a feature-removal release, removing support for features already marked as going away by the end of the 2.x series and which have replacements. c) don't make any radical syntax changes which make it impossible to write code that can even parse in both versions. d) for all backwards-incompatible-change proposals, have a section dedicated to compatibility and migration of old code that explains both how to modify old code to do things purely the new way, _and_ how to modify code to work under both the old and new ways. Strive to make this as simple as possible, but if totally necessary, it may be reasonable to suggest writing a wrapper function which changes behavior based on python version/existence of new methods. James