Evolving Python and PEP238

Paul Prescod paulp at ActiveState.com
Tue Jul 24 13:15:02 EDT 2001


David Bolen wrote:
> 
>...
> And as pointed out elsewhere, my systems and installed base are not
> incrementing through each release as they occur because of the cost of
> doing so.  I'm still managing a base of 1.5.2, and will likely jump
> from that right to a release like 2.1 (or maybe 2.2 depending on my
> timing and availability of dependent extensions), so it's all too easy
> to end up skipping over the "warning" release right into the "break"
> release.

I notice that people keep mentioning Python 1.5.2. That was a
particularly popular release of Python and people seem not to care much
about releases before that.

Now consider if Guido says: "I'm going to be changing a behaviour that
was deprecated in 1.4 and has issued a warning since then. Any
complaints?" Would anyone here complain? I doubt it. The offending
feature would have been expunged from the collective consciousness so
long ago that people would not even remember it.

So the backwards compatibility question is a function both of how severe
the change is and *how quickly it is made*. 

Python is around 11 years old. If Guido had embarked on this PEP238 path
7 years ago, the backwards compatibility problem would also have been
severe for the code created in the first 4 years but by now most people
would not know or care about the fact that there was 3 or 4 year period
where divisions had to be migrated over slowly. Today, the period of
transition would be merely a mythical historical event like the Great
Usenet Reorganization.

For anyone who doesn't know: Guido doesn't really have a time machine.
Time-delayed deprecations his only way to fix most bugs in the language. 

The Python community is still growing fast. I expect Python to be around
for at least another 11 years. We should be planning for that future.
Python is important enough to have a long-term plan like your retirement
plan and the plan for how you are going to send your kids to school and
how America is going to save Social Security. (oh...wait...scratch that
one)

It is one thing to argue that this change is not the right one. I
disagree but we can cover that in another discussion. It is another
thing to say that Python is a language that can only accumulate warts
and never remove them. I think that that is an unnecessarily defeatist
attitude. The mechanism for making "big" changes is well-defined and
entirely workable. It merely requires patience and a sense that Python's
future is important enough to have a long-term plan.
-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook




More information about the Python-list mailing list