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:Just rename it.

[Kludge]

Too many kludges will confuse people. Yeah! Get lost all you wanna be's!

Seriously, what really matters is:
#!/usr/bin/python2
or
#!/usr/bin/python3

And I'm betting someone will come up with
#!/usr/bin/python
that will automatically determine which python it is from the syntax.

Re:Another Shock Story

[betterunixthanunix]

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

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

Re:print as function vs. keyword

[Wiseman1024]

A good one though. Statements are stupid. Probably Python's biggest flaw. It's good that they're getting rid of a couple of them, though while, if and the like still remain.

If you're wondering why statements are stupid: they are not first class values you can pass, use and manipulate; they introduce a special, harder to learn and very quirky syntax; they cannot be used anywhere and thus subtract flexibility; and they are an extra form or feature that's actually unnecessary ("Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary." - R6RS, Introduction, best piece of insight on software design ever).

The difference between print >>lol, wtf and print(wtf, file=lol) is that, in the later case, print is a first-class value (a function, in this case) that I can pass to another function should I need it to call it back, or use in the middle of an expression.

Re:It's a race

[misleb]

While both Perl and Python are in need of a fat trimming in terms of obsolete and redundant language features, I think Python has a small enough user base that they could actually pull it off.

Re:It does have block statements.

[Fweeky]

Copying and pasting code in any language requires you to reindent it just as much as with Python, lest it become an unreadable mess, Except with delimiters I can just type gg=G and I'm pretty much done.

Re:It's a race

[misleb]

Yes.

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:It's not like this is the first time.

[rk]

You're not alone! I started with Python 8 years ago using 1.5.2 as well. I liked python then, but when python 2 came out, I went from liking python to it becoming a favorite language. I looked at one of my old python 1.5.2 scripts a couple weeks ago, and it looked very odd and a little clunky to me. If python 3 someday makes me look at my python 2 code in the same way, then as far as I'm concerned, it's all good.

Re:It's a race

[chromatic]

No one has to fix bugs in Perl 5 besides a couple of people at ActiveState, which has customers. People work on Perl 5 because they want to. (I still send in patches occasionally, even if I spend most of my available time working on Parrot.)

Re:Whiners

[Anonymous Coward]

It's not the same thing at all. When companies remove compatibility, you're SOL. When free software removes compatibility, I can still run the old version, or port the old version to a new OS, or hire somebody to do that for me.

If companies did the equivalent thing -- "the new version won't be backwards-compatible, but we're open-sourcing the old version" -- I don't think anybody would complain.