[Python-Dev] Re: PEP 328 -- relative and multi-line import

[Paul Prescod]

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