Python 3.0 To Be Backwards Incompatible

Stony Stevenson writes "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, Linux.conf.au attendees were told this morning. The Python development community is working towards a new, backwards-incompatible version of the language, version 3.0, which is slated for release in early 2009. Anthony Baxter, the release manager for Python and a senior software engineer at Google Australia, said "We are going to break pretty much all the code. Pretty much every program will need changes." Baxter also added another tidbit for attendees, saying that Python accounts for around 15 percent of Google's code base."

It's a race

Will the new Perl or the new Python be the first to shoot itself in the foot with incompatibility?

Re:It's a race

From Perl 6 FAQ (http://dev.perl.org/perl6/faq.html)

> Will I be able to convert my Perl 5 programs to Perl 6?

> Yes. Larry Wall and others are already working on a Perl 5 to Perl 6 translator, which will be able to translate (most) Perl 5 source code to the equivalent Perl 6 syntax.

> In addition, Perl 6 will provide a "Perl 5 compatibility mode", allowing the compiler to directly execute any code that it recognizes as being written in Perl 5.

Depending on who you talk to, this can be said to be backward compatible.

Just rename it.

Call it "Cobra" or something. Too many kludges will confuse people. A new name and file extension will emphasize that this is "in with the new".

Re:Just rename it.

There are already other [wikipedia.org] languages [wikipedia.org] doing this. If you think naming closely-related languages the same thing is a kludge, what do you think of naming mostly-unrelated languages the same thing?

Re:Just rename it.

The vast majority of the language and standard library will remain the same. This is just about tidying up some unfortunate warts that affect a lot of people, such as unifying the different string types. It remains Python in practically every way, and renaming it is simply unnecessary.

Re:Just rename it.

Python's named after the troupe Monty Python, not after the snake species. I don't think renaming it is a good idea, but suitable successors would be [Life of] Brian, [Fish Called] Wanda, Flying Circus, Holy Grail or perhaps start with sub-versions like Cleese, Chapman and Palin.

Alternatively, pick another troupe or favorite comedy show: Fry and Laurie, Mr. Bean, Fawlty Towers or Red Dwarf. Or my favorite, which brings back in the snake species AND British comedy into circular pun, Blackadder.

While talking about puns, snakes and coming full circle, I suggest Ouroboros.

Another Shock Story

If the editors read the article rather than posting shock stories, Python 2.6 will also be released at the same time and will not break backwards compatibility. Python is not pulling the rug out from under its developers as the summary would lead you to believe.

Re:Another Shock Story

No, but that means that everyone planning to run non-Python3 code will have to maintain two parallel Python installations. With package management that's not so bad, but it still puts a bit of pain on distro maintainers.

Yet everyone makes fun of me when I say that I am a C++ programmer.

Re:Another Shock Story

It is an issue though. PHP did exactly the same between version 4 and 5, and it crippled adoption of 5 because hosts refused to upgrade as it'd have broken too much code. It was a full 3 years or so before 5 was really considered the primary version amongst many developers and that took the announcement of 4.x support ending and the success of the GoPHP5 campaign.

Hopefully the Python team will learn from PHP's experience.

Workaround...

I think I have a Perl script that'll fix this...

Just kidding Python fanbois :-)
Chill, it's Friday.

Re:Workaround...

Actually, Python2.6 is slated to include a tool which will update purely syntactic differences to Python 3 automatically. There are some issues it won't be able to fix, but Python2.6 will have a mode which will generate warnings about those so that they can be fixed well before Python 3's release.

print as function vs. keyword

The biggest incompatibility is how you output to stdout. Instead of doing

    print "This used to work"

You now have to do

    print("This is how 3.0 rolls")

There will be no grandfathering, so everything needs to be refactored accordingly.

A small, but significant change.

Re:print as function vs. keyword

Actually, the migration tool 2to3 performs this change automatically, and the function call approach works in both 2.5 and 3.0, so the incompatibility is greatly exaggerated.

I don't see the problem

While it would be nice if it were otherwise, sometimes you need to break with the past to develop solutions to problems. It's an ugly, but very real truth. Thats not to say that my I will be rewriting my code to 3.0 immediately, but sometime in the next year or two I probably will.

We have options.

I maintain tens of thousands of lines of Python... and I'm not worried. Why? Because I am sure they will continue to support security and bugs on the 2.x line for a long time to come.

It is not like your favourite Linux distro is just going to drop the 2.x series overnight, or like Python 3 will fight 2.x on your system.

Whiners

We whine when companies break compatability, yet we whine just as loud about bloated software when companies leave in compatibility.

Tell, me exactly what would satisfy you? How about we just take your computer away.

I'm running for president! FREE PACIFIERS to all Slashdotters. ;-)

Re:Whiners

It's almost like there's more than one person with an opinion on this!

meh

As long as you can run Python 2 & 3 in the same environment, this shouldn't be a big deal.
It'll just be a case of slowly moving code from one version to the next.

This is a brave move, but you've only got to see the mess you can get into trying to force backward compatibility for too long (Vista, anyone) to know it's the right move.

Of course, this being python, I fully expect some brainbox to come up with an automated conversion routine (v2 to v3) that "WAS WRITTEN IN ONLY 15 LINES OF CODE". etc, etc.

in fact, such a utility already exists

http://svn.python.org/view/sandbox/trunk/2to3/ [python.org]

And, as others have stated, there'll be the 2.6 branch, which will be backwards compatible.

Or, in other words, the story is stupid and misleading.

Python is doomed

Look at C++, they broke backwards compatibility with C ( malloc casting for example ) and because of that it never became mainstream.

Almost 2 years old?

People only reading the summary and shooting from the hip should realize:

• Python 3 (or Python 3000 as it was called) as a serious effort is more than a year old.
• There is already a working interpreter in its second alpha release.
• Final release is slated for August. (No infinite Perl 6 development.)
• Developers are working very hard to make the 2 to 3 transition as painless as possible.
• The Python team is committed to keeping the 2.x series going until 3.x has clearly been accepted.

You may now proceed to complain having been thus informed. :)

For more info, check out

The "What's New for 3.0?" article over on python.org:

http://docs.python.org/dev/3.0/whatsnew/3.0.html [python.org]

Not news in any way

This has been known for donkey's years. Guido has been talking about this compatibility break since the 90s. The changes were laid out in detail in PEP 3000 [python.org], first published in 2006. They have already released two alphas. A conversion tool to automatically make some of the required changes (such as changing print statements to print() function calls) already exists [python.org].

If this is news to you

&& you use python, please turn in your developer card

Re:#1 way to prevent adoption of new language vers

Relax.

First of all, the changes are mostly simplifications to the core language (e.g., how to catch exceptions is currently a bit of a mess if you want to catch more than one exception). So for example, range and xrange are now one, iterators become more prevalent, "old-style" classes are going away and so new-style ones will become the standard, a lot of the things that have been deprecated now are being removed, etc. It isn't really a "new language" in any sense. This is far superior to Java's "always backwards compatible" approach which has lead to a lot of cruft building up over the years.

Next, it needs to be understood that 2.6 will be backwards compatible and include a warnings mode to highlight things that won't work in Python 3.0 to ease in the transition. There should be no problem supporting both on one system.

Finally, they are providing a 2.5->3.0 translation tool that runs in 2.5 and does most of the mechanical translation between the two for you.