Slashdot Mirror
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."
Will the new Perl or the new Python be the first to shoot itself in the foot with incompatibility?
Intron: the portion of DNA which expresses nothing useful.
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".
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.
Just kidding Python fanbois :-)
Chill, it's Friday.
It must have been something you assimilated. . . .
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.
- Despite popular opinion, I am not perfect.
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.
Ubiquitously - A Ubiquity Developer Community
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.
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.
Mike @ The Geek Pub. Let's Make Stuff!
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.
Training monkeys for world domination since 1439
Look at C++, they broke backwards compatibility with C ( malloc casting for example ) and because of that it never became mainstream.
\u262D = \u5350
- 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.The "What's New for 3.0?" article over on python.org:
http://docs.python.org/dev/3.0/whatsnew/3.0.html
- Despite popular opinion, I am not perfect.
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.
Bogtha Bogtha Bogtha
&& you use python, please turn in your developer card
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
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.
Exactly! Now they can force people to buy expensive IDE's and servers to run the new version of Python, and strong-arm people into purchasing licenses to use the language for commercial purposes. It's just a money making ploy.
Oh, wait a minute. All the old versions are going to continue to be available -- even the source code. And it will remain free for commercial use. Hmmmm.
Sorry, but I fail to see how what they are doing is at all like Microsoft.
quiquid id est, timeo puellas et oscula dantes.
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.
Integrate Keynote and LaTeX
Why, exactly, is it that it should never have semantic meaning? Is there a rule somewhere?
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:
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.
Beware of bugs in the above code; I have only proved it correct, not tried it.
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.
rage, rage against the dying of the light
PHP 5 was a MAJOR over-haul, biggest since PHP 4. When PHP 4 came out, hosts and OSes supported 3/4. PHP 3 has really cool, but extremely insecure, syntax things for web prototyping. When you posted a variable, put it on the query string, or passed it in a cookie, it just came into the script as ${name}. So if you needed to check for setting, it was isset($variable), using it was just using it, etc. This was dangerous because in PHP you don't declare your variables, so if you assumed that a variable you never zero'd/nulled before usage was null at the beginning, this could be exploiting by posting a value.
PHP 4 had a php.ini setting to use the old mode (I think register globals or something similar) that helped in the migration. Also, include_once/require_once massive simplified using libraries. Before that we had to do our own equivalent of ifdef/ifndef in our PHP code to avoid overwriting a function if two included libraries called it.
The PHP 3 -> PHP 4 transition took a while as well. What's the rush, my new systems all include PHP4 AND PHP5. All my new code is PHP 5. My PHP4 stuff happens to be in legacy mode, but if I needed to bring it will us, you put it on a machine and see what works, what doesn't, and add support for 4 AND 5, like we all used to do on PHP 3/4.
Better to introduce some source incompatibility for improvements then not being able to move forward, just make sure that there is a transition strategy. Three years isn't really that long... though when I started in web stuff, 3 years was an eternity, but 8 years later, eh, just a few more years.
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.