Bill Janssen wrote:
Also, by the time imports start to fail, what is currently two or three year-old code will be five or six years old. Anyone who is writing code now will be aware of this issue and should be able to future-proof their code if they want. Nobody should expect to download code that's five or six years old and have it just work.
I expressed myself poorly; I was thinking of packages written in the future, so they'd still be two or three years old.
"Anyone who is writing code now will be aware..." is an unfortunate example of ivory-tower thinking. Many people who are writing code using a wonderful tool like Python have better things to do than keep up with the vagaries of Python releases. They rightly feel that if they learned Python with 2.2, what they know should be pretty stable at least until Python 3.0 comes out.
Most people in the Python community know that Python doesn't really have "minor releases" other than bugfix releases. Just like Linux and Perl, the choice to switch to a big version number is more marketing than anything. (and it says something about our marketing saavy that we've done it exactly once)
... They don't think that in a minor release, Python import semantics will change out from under them. Every few years, when they find some time, they will check out some of the new features, like generators, that the developers find so delightful. But in between those times, they won't be clueful.
It really just boils down to a question of how much time you give people. First you try to publicize the change via books, tutorials, mailing lists etc. Then you add an annoying warning. Then eventually you break the old code. If you move slow enough then I claim you can make an arbitrarily deep and pervasive change without significant user pain. For example consider the shift over the years from K&R C to ANSI C to C++. It wasn't totally painful but it was never so painful as to make people switch languages on the basis of backwards incompatibility pain. And there were some pretty major changes in there...the deprecation of implicit casting of void * being one that pops to mind.
One of the attractive features of Python has always been that 5-year-old code *does* just work. That's because the design was largely right from the start, and the designers have been careful to keep things backwards-compatible.
5-year-old code OFTEN just works. But not always. Each version of Python has a document that describes incompatibilities. http://www.python.org/1.6/ http://www.python.org/2.2.3/bugs.html e.g. "The special attributes __members__ and __methods__ are no longer supported (for most built-in types). Use the new and improved dir() function instead." Admittedly this relative import change is a big one compared to those from the past. My opinion is that that just means it should be done a very long time after the version with the warning ships. My opinion is that the process is correct and it is just a question of whether the timelines are generous enough or not. Somewhere between "Python 2.6" and "never" there must be a point where people have had enough time to change over their code after getting nagged by the DeprecationWarning. Paul Prescod