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

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

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.