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."

Comments

It's a race

[Intron]

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

Re:It's a race

[Incongruity]

See, the funny thing is that the changes going into Python 3 are fixes for much of what people have complained about in Python 2.x and prior.

Moreover, every step of the way they've built translators to move code from 2.x compatibility to 3.0 compatible -- and it'll catch when it can't translate the code and tell you as much. It seems pretty slick from everything I've seen. In many cases the fixes are ones you could easily do yourself in seconds with a good text editor. This will be a minor speed-bump for most users

For more info, check out the recent Doctor Dobb's Journal interview (audio) with David Goodger -- it's about PyCon 2008, but it also covers Python 3 as well.

Re:It's a race

[BOFHelsinki]

15% of the google codebase consitutes a "small user base"? Why, yes. Google is a big user but still just one user. So if 15% of Google uses it, it's only 0.15 users. That's a very small user base. Even Mono has a larger user base (Miguel).

Just rename it.

[Besna]

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.

[Neil Hodges]

There are already other languages 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.

[Bogtha]

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.

[Tritoch]

You could call it "Asp". Oh, wait...

Another Shock Story

[LowSNR]

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

[onion2k]

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...

[fahrbot-bot]

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

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

Re:Workaround...

[tuffy]

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

[spookymonster]

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.

I don't see the problem

[Urger]

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.

Whiners

[MikeDataLink]

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

[19thNervousBreakdown]

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

Python is doomed

[Arthur B.]

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?

[Anonymous Coward]

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. :)

in fact, such a utility already exists

[Reality Master 201]

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

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.

Breaking backwards comp. in languages good

[Crazy Taco]

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

You know, sometimes a little backward incompatibility can be good. You can shoot yourself in the foot more by not breaking things when something needs fixing. As an example I point to VB.Net.

Back in the days of VB 6 and prior, VB was an entry sort of language that was designed with novice programmers in mind, and strayed quite a bit from normal programming constructs. With the advent of the .Net platform looming, Microsoft wanted to move VB to .Net, but didn't want to break existing code out in businesses. So they opted instead for kludges and workarounds in the language, and that's the reason I can't wait to get done with VB .Net project I am currently writing. If you are an experienced programmer in other languages such as Java, C++, etc, VB .Net can drive you mad. Here are just a couple examples:

1. Arrays. VB did not originally have 0 based arrays. Its arrays started at 1. In order to get VB to work with .Net, Microsoft really turned arrays into a kludge that is very difficult to remember (I almost always have to pull out an O'Reilly reference) and easy to get wrong. In a normal language, you declare an array of five integers and you get five slots numbered 0 through 4, right? Well not VB .NET! You declare an array of five integers, and you get SIX slots, numbered 0 through 5. And where most languages you would see "something - 1" when referencing array locations, in VB you often see "something - 2"! That really makes things annoying, especially if you've worked in .NET before with C#, because when you come over to VB you are almost guaranteed to biff things up.
2. Logical operators. In the original VB, "And" and "Or" operators did NOT do short circuit evaluation. To avoid breaking code, Microsoft introduced even more operators, "AndAlso" and "OrElse". Those two operators are just like "And" and "Or" except that they do do short circuit evaluation, but good luck trying to remember to use them when coding quickly. I know when I code and want to "And" things together, I think "X And Y", not "X AndAlso Y". Therefore, these new kludge operators certainly aren't the default operators most people think to use, so most end up using "And" and "Or" in the heat of coding, and VB code suffers and unecessary performance hit all over because short circuit evaluation isn't often used.

There are many other examples in VB like this, so I say this to the Python developers: If you have a good reason to break backwards compatibility with the language, then do it. Keep backwards compatibility whenever reasonably possible, but break it before accepting a kludge into your language. Your future coders will thank you, and will not run away screaming to the other, newer languages that will inevitably follow.

Re:Damn right

[pthisis]

1. Python 2.6 is still due out and will be supported for years.
2. Python 3.0 includes a 2to3 script to convert existing Python code to Python 3
3. The incompatibilities are mostly mechanical, by far the largest is the change of "print" from a statement to a function (which simplifies the implementation and makes converting existing programs to log to files or whatever much easier). I've yet to find any of my code that 2to3 doesn't handle just fine.