Python 3.0 to be backwards incompatible

“Organizations using Python will be affected in a major way by changes in store for the language over the course of the next twelve months, attendees were told this morning”, reports

I hate it when this happens. The fact that you might be able to install Python 2.x in parallel does not make this any better. It’s just stupid when developers break compatibility — even if they have a good reason for it. As a user, I just plain hate the consequences.


Tom Dison wrote on February 1st, 2008 at 11:06 AM PST:

I think every once in a while you have to bite the bullet and break compatability. There were essentially several design flaws in Python that were allowed to continue for years. For Python 3.0 they decided to fix them. The same is true for the (as yet phantom) Perl 6 version. It will break a few things for the sake of sanity. It reminds me of how Microsoft (and even Intel) have managed to drag along the baggage of the original 8-bit IBM PC for the sake of backwards compatability. I predict at some point they will have to let it go.

I don’t think it will suck too much for users. Most software will continue to use

Alex wrote on February 1st, 2008 at 11:41 AM PST:

How else is the language supposed to move forward if it can’t break some compatibility between major versions? It isn’t a minor release!

You can always install both on the same machine if certain applications only work with an older version of Python.

This is the admin speaking...
Eugenia wrote on February 1st, 2008 at 11:54 AM PST:

C and C++ haven’t broken compatibility for a long time. There are standards. You get it RIGHT the first time, or the second one. That’s what engineering means. After so many years, Python’s spec should have been stable by now. There is no excuse other than bad engineering.

Timothy wrote on February 1st, 2008 at 1:51 PM PST:

There’s a bit of a difference between C/C++ and Python. C/C++ is rather low level. They don’t do to much, they have pointers, classes, etc. Python however, with iterators, maps, and all the other tons of stuff it includes, it’s harder to get it right “the first time”.

I’m glad they are doing it right, and not trying to keep the cruft in. As Tom said, we have enough of that sort of junk from Intel.

Tom Dison wrote on February 1st, 2008 at 1:54 PM PST:

Actually, things do change in the C/C++ world. Things get marked as deprecated, and then developers need to change their code before these deprecated methods go away. The same is true in the Java world. The same just happened in the move from Php 4 to 5 to 6. Register globals were marked as deprecated for a long time before going away in PHP 6. A lot of developers just continue to use deprecated functionality. That’s why the implementation of Python 2.6 will clearly mark deprecated methods, facilitating the change to 3.0. This reminds me of the change from K&R C to Ansi C. A lot of developers dragged their feet on that, but they were necessary standardization changes.

Steve Bergman wrote on February 2nd, 2008 at 6:14 AM PST:

This is very much a matter of programmer/admin taste. Python has always made certain changes between releases which can break some programs. It’s a bit of a pain. But it does allow the language itself to improve more than it would if they were completely tied to backwards compatibility. Python 3.0 will be the first really major change to the language in its long 17 year history. It is intended to fix those design irritations which developers have just had to live with until now.

I think that most Python programmers are OK with the 3.0 changes. Of course, you could make a good case for us being a self-selected group who don’t mind a little backwards incompatibility in return for what we get back. Then again so are C++ programmers, who live in a hell of their own creation and seem to enjoy it. andTheSameCanBeSaidOfJavaProgrammers().


Steve Bergman wrote on February 2nd, 2008 at 7:40 AM PST:

Yeah, I know I’ve already replied. But I had not read Eugenia’s comment at the time. I guess I would have to ask you to define “RIGHT”. Is “RIGHT” agreed upon by everyone? And is it forever?

To the extent that there are some decisions that Guido made back in 1990 that he and the current dev team would have made differently today, in 2008, I guess you could say that it was “bad engineering”. But I think that’s a pretty loaded phrase.

You could actually make a better argument that the Python dev’s philosophy on compatibility has negative repercussions regarding use of the language in certain common settings. And I would not argue with that view because it’s true.

I believe that the extent to which Python is used *despite* the small version to version incompatibilities, and this long-known and upcoming bigger break in compatibility.

I know that blogs are for rants and I respect that. But calling Python 2.x “bad engineering” seems a bit over the top to me.

Steve Bergman wrote on February 2nd, 2008 at 7:45 AM PST:

Yeeks, third post. Need caffeine. But one of my previous sentences doesn’t even make sense and that embarrasses me more than making three posts in a row and having to deal with yet another CAPTCHA. 😉

Should be: I believe that the extent to which Python is used *despite* the small version to version incompatibilities, and this long-known and upcoming bigger break in compatibility *speaks for the quality of the engineering which has gone into python thus far*.

I’m leaving for a client site now so this should be my last installment.

Comments are closed as this blog post is now archived.

Lines, paragraphs break automatically. HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

The URI to TrackBack this blog entry is this. And here is the RSS 2.0 for comments on this post.