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

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

[pthisis]

Python2.5 and later let you write 3.0-compatible code. Just put parens around your print statements and you're probably fine to run in 2.5, 2.6, or 3.0. There are a few other changes which 2to3 and the 2.6 interpreter will warn about, but they're relatively rare. e.g. range will return an iterator instead of a list; code like:

for i in range(1000):
        # do something

will remain unaffected, but code that does something like:

a=range(1000)
a[37] = 2000
for i in a:
      # do something

will be affected.

The conversion tool and 2.6 interpreter will warn you about those things, and they're easy to fix ( "a=list(range(1000))" ) if 2to3 doesn't do them automatically. Which I'm not sure about, because they're highly unusual--2to3 has converted all of my personal code just fine.

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.

Re:print as function vs. keyword

[Bogtha]

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.

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.

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

For more info, check out

[spookymonster]

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

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

Not news in any way

[Bogtha]

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

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.

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:It's a race

[Anonymous Coward]

Is Perl 6 backward-compatible with Perl 5?
No.

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

[Llywelyn]

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.

Re:It's a race

[IkeTo]

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.

Re:Just rename it.

[orclevegam]

Because whether or not it's a lie is largely a technical question that's somewhat open to interpretation. If by backwards compatible you mean is the old Perl5 syntax valid Perl6 syntax, then the answer is no. If however you mean will my old Perl5 scripts run in the Perl6 interpreter, then the answer is yes. Further more the old Perl5 modules (as per your link) will still be usable from Perl6, and there will be a converter to update the Perl5 scripts to Perl6 syntax. So, a better answer to the question of "Is Perl6 backwards compatible with Perl5?" might be "maybe".

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.

Re:It's not like this is the first time.

[slackergod]

Indeed. You should read up on the changes they're planning to make.
Many of them are backwards-incompatible changes that will remove nasty warts,
realign certain parts of python's object structure (str vs unicode, int vs long)
in ways that are MUCH cleaner, MUCH harder to make mistakes with, etc.

This is not some Larry Wall day dream revision...
they aren't rethinking python from the ground up,
it's an evolutionary revision which is keeping the python 2.x codebase,
but changing some things they've been wanting to do for a long long time.
The 1.x -> 2.x transition is apt... the code will look almost the same,
only cleaner :)

If that's not good enough for anyone, automated tools are being developed
to convert python 2.6 -> 3.0. Yes, that's right, Python 2.6. It'll
be the last version of 2.x released, and be carefully designed to be
both compatible w/ 2.x, and still able to warn you about gotcha's
that would appear if you ran the code under 3.0.

Not only that, but 3.0 isn't projected to be in mainstream use
for at least 2 more years.

There's absolutely no need for the sensationalist panic this slashdot headline
annouced itself with. Rethinking a complex system from the ground up is always
a bad idea... but GVR knows that, and that's not whats happening here.

It's more akin to the linux kernel moving from 2.4 -> 2.6
Incompatible, yes, but a much better architecture.

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:Python to not be backwards compatible

[Kadin2048]

If it isn't backwards compatible, it isn't Python, as far as I'm concerned. I'm sure not going to be re-writing a couple hundred megabytes of code. They can take their incompatible new snakelike thing and smoke it. Foregoing backwards compatibility is about as dim a move as I've ever seen anyone outside of Microsoft pull (MS dropping VB underneath Access comes to mind as a comparable clueless act, with exactly the same consequences — it isn't the same product and is useless to me.)

I don't think anyone is really suggesting that a lot of code be rewritten. Python 2.x isn't going anywhere, for exactly the reasons you bring up. Python 3.0 is going to be almost a completely new product, and I expect it'll only be used for new projects. I'm not really sure why anyone would want to convert their old code, if it works for you the way it is.

The reason for breaking compatibility is to maintain the Python philosophy of not having a lot of ways to accomplish the same thing. Without periodic pruning, eventually you'd just have Perl with indents.

From what I've read, you'll be able to choose the version/style you want, and the 2.x and 3.x series will live alongside each other (I don't know whether the 3.x interpreter will have a compatibility mode, or if you'll have to keep the 2.x version around as a separate program, though).

Re:Breaking backwards comp. in languages good

[Doctor Faustus]

Its arrays started at 1. In order to get VB to work with .Net
This was actually introduced prior to .Net. I'm not sure when, exactly, but VB6 is the same way. Actually, VB6 is pretty schizophrenic about 0 vs. 1 based indexes in general. I used to make a habit of just putting in a breakpoint and looking at the array while the program ran, instead of trying to remember which was which.

Personally, I like the way Turbo Pascal made you declare both upper and lower bounds. 0-based arrays make sense in a systems programming language when it's just a thin veneer for a pointer, but VB, C# and Java shouldn't force it on you.

In the original VB, "And" and "Or" operators did NOT do short circuit evaluation.
Beyond that, they were bitwise operators, not logical. The fact that 1 is true, 2 is true, but 1 AND 2 is false is far more perverse than the lack of short-circuiting. This is also why the canonical true value in VB is -1 (1111111111111111 binary) rather than the usual 1. This was appropriate in Bill G's 8K Altair BASIC, but it should have been fixed in MS BASIC well before 1980.

VB.Net Beta 1 made "And" and "Or" normal logical operators and introduced new bitwise operators for the old functionality, but too many people complained and they switched it back for Beta 2.

There are many other examples in VB like this
I don't know about that. Those are pretty much the worst parts that .Net didn't fix. There are some clunky IO libraries clearly designed to be used by the migration wizard, but they're strictly optional. Plus, I really like that VB.Net still has real optional arguments, as opposed to C# that goes the Java route and makes you declare a little stub version with fewer arguments that just calls the real one and fills in a default value.