Python 3.0 To Be Backwards Incompatible 438
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."
It's a race (Score:5, Insightful)
I don't see the problem (Score:5, Insightful)
We have options. (Score:5, Insightful)
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.
Whiners (Score:5, Insightful)
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.
meh (Score:5, Insightful)
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.
philosophy (Score:3, Insightful)
IIRC, even dot-releases of python are not source-compatible. I assume that's why my install of Ubuntu has multiple versions of every library, e.g., /usr/lib/python2.4/smtplib.py and /usr/lib/python2.5/smtplib.py.
I think this is partly a matter of philosophy. The people in charge of a particular language tend to be computer language enthusiasts, and they like to tinker with them. They say things like, "The language has to be able to continue to evolve, or else it will die," or "We don't want to lock in things that, in retrospect, were really mistakes." But people actually using the language typically put a higher priority on not having their code break. Obviously we wouldn't all want to still be writing old-style fortran, with fixed columns, Hollerith codes, etc., but I also don't agree with the philosophy that "bit rot" is inevitable, and every piece of code you write is like a baby that you have to tend for the rest of your life. Personally, one of the things I really like about Perl is that it's got an excellent, mature implementation, and it's been mature for a long time. This is a lot less true for Ruby, for example, in my experience. It's true that Perl 6 is going to break backward compatibility with Perl 5, but the Perl 6 interpreter is going to automatically recognize Perl 5 code, and handle it correctly.
If this is news to you (Score:5, Insightful)
Re:Whiners (Score:2, Insightful)
Tell, me exactly what would satisfy you?
There's an obvious and simple solution that these stupid developers could implement if they weren't so lazy. As soon as they are done with the new backwards-incompatible code base they should just go back in time, preferably before I ever learned any code, and release it then. That way, all of the Python code I've written would have been 3.0 compatible from the start.
The Microsoft route (Score:4, Insightful)
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.
Re:Just rename it. (Score:1, Insightful)
Re:Use (Score:1, Insightful)
* Parrot, Haskell and Common Lisp
Re:Sad day (Score:3, Insightful)
Re:Another Shock Story (Score:3, Insightful)
Not a big issue for Python, methinks. Python is not generally used in hosted environments like PHP is. At least not in the same proportion. PHP's only real strength is its install base. You can get it on just about any host. To make a comparison outside of languages, PHP is like WIndows. The major selling point is its ubiquity. In which case, compatibility with the rest of the install base becomes first priority. Python's strength, on the other hand, is Python.
-matthew
Re:So, will it FINALLY have block structures? (Score:5, Insightful)
Why, exactly, is it that it should never have semantic meaning? Is there a rule somewhere?
Re:So, will it FINALLY have block structures? (Score:3, Insightful)
I find that your criticism falls at a surprisingly shallow level of thinking. You would think that someone familiar with Lisp would be able to see beyond the first layer of a language and recognize that the strength or weakness of Python has little to do with syntax details that take five minutes to accept. The simplicity, flexibility, and overall utility of a language's cognitive model is more important, and it seems like whining about syntax is little more than noise in an important debate. Yet for some reason, the use of whitespace in Python inspires an obsessive response from people who happily ignore the (debatably worse) syntax crimes of Perl, Ruby, or C++.
Re:It's a race (Score:3, Insightful)
The question is, who is going to have the hardest time interfacing to existing code?
In either case, things are changing that could present challenges to this. Perl is going to a new virtual machine. Python is changing things like string handling. Either one could he a show stopper when it comes to using existing code.
Neither Perl 5 nor Python 2 is going away. Interfacing with existing code would be a huge boost to either Perl 6 or Python 3, but of the two, I think Python 3 is more likely to catch on even if it is incompatible. The reason is this: people use Python either for its lexical and syntactic simplicity, or because they want to build products for something like Zope. The Zope users won't touch Python 3 until Zope runs on it; afterwards they'll use whatever its available for. The people who use Python as a kind of "programming in pseudocode" language will adopt Python 3 if it looks cleaner.
Perl, on the other hand, is about diversity. A Perl programmer working in a version of Perl that doesn't interface with Perl 5 is cut off from a big part of that diversity. At the very least, nearly everything in CPAN needs to be usable in Perl 6; but there are also countless systems built around mod-perl or even perl cgis. Perl is not, in my opinion, clearly superior to other scripting languages available today. What is uniquely valuable about Perl is the whole software ecosystem built around perl since the 1980s.
I hope that "incompatible" only refers to source in both cases. It looks like the biggest headache for updating Perl 5 code to Perl 6 is going to be the fact that "@foo[0]" will be the first element of the array @foo which we'd write as "$foo[0]" in Perl 5. This kind of change shouldn't make it impossible to call Perl 5 routines from Perl 6. A lot of the Perl syntax and lexical changes seem to either be sugar, or to provide optional ways of making your code more easily optimizable. TFA doesn't say much about the new Python changes, but of the ones I've heard about, the only one that really is a show stopper is the change to unicode for all strings. It's a good thing, in my opinion, but if you want to call an older routine, the lack of formal parameter typing would mean you'd need to know to convert any strings to byte sequences.
Re:So, will it FINALLY have block structures? (Score:1, Insightful)
Guys, block structured languages you can trivially derive pretty-printing formatting. Which means you get the "easy to read" ability trivially. You should NEVER read the Silly Parenthesis in LISP, that gets taken care of for you by any one of a gazillion tools.
But you can't go the other way around.
EG, on C, you can cut and paste trivially. You can't on python, you need an editor which parses the language sufficiently to understand that "This is a code block going into a different code block".
Likewise, code generation. Its trivial to build a recursive code generator targeteing "pick your favorate block structure language". But in Python, you have to explicitly add a notion of "what depth is my recursive code generator actually operating at", and "woe to you if you forget a linefeed".
Next thing you know, slashdot will be full of defenders who insist that Make's treatment of tab and space is a good thing.
Like so much of Windows, whitespace-as-block-structure is a bug, not a feature.
Re:It's a race (Score:3, Insightful)
At least the first form of "backward compatibility" mentioned (a translator for most older code) is also available (or a planned feature) for Python 3.0.
Much like python's approach (Score:3, Insightful)
Re:Duh (Score:2, Insightful)
Very true, but we do give you the complete source code to all of our older versions. Go crazy.
How did that Cripple PHP (Score:5, Insightful)
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.
A cunning plan (Score:3, Insightful)
Re:So, will it FINALLY have block structures? (Score:3, Insightful)
A=[[ 71, 211, 211, 131, 221, 131, 201, 221, 81, 214],
[ 131, 161, 141, 221, 51, 81, 171, 1, 241, 160],
[ 31, 201, 91, 41, 71, 111, 111, 191, 181, 34],
[ 171, 161, 171, 251, 161, 51, 141, 241, 101, 53],
[ 91, 81, 131, 61, 71, 141, 201, 251, 191, 155],
[ 221, 71, 111, 61, 121, 191, 11, 201, 61, 161],
[ 211, 81, 171, 221, 11, 131, 151, 111, 111, 94],
[ 151, 131, 151, 181, 251, 161, 11, 121, 231, 147],
[ 121, 181, 201, 31, 141, 51, 101, 51, 171, 115],
[ 231, 71, 241, 1, 101, 91, 71, 161, 51, 11]]
If that was your argument to show that `python forces you to write horribly formatted code', well, you need another argument.
In any case, have you seen the huge amounts of pretty good python code out there? I have yet to see something which would rightfully be described as `horribly formatted'.
Comment removed (Score:4, Insightful)
Re:So, will it FINALLY have block structures? (Score:1, Insightful)
And just what do you suppose is the quickest way to move a block of code out from its current location, possibly nested inside various conditionals, loops, etc, to a (presumably top-level) function?
Re:Breaking backwards comp. in languages good (Score:3, Insightful)
Re:Python to not be backwards compatible (Score:3, Insightful)
I wrote a LAMP app for my school, a simple tardy slip program. since I had older versions of A(1.3)M(3.x)P(4.x) on my ibook to develop on, and all we had were PC's at school, I downloaded an older version of fedora (I think) with the older versions. since everything copied over easily, install/set up was no problem. it's been up and running for a year and a half. could I do it with 2.x, 5.x, 5.x? sure, but I am not in the mood to rewrite.
Comment removed (Score:3, Insightful)
Re:Python to not be backwards compatible (Score:4, Insightful)
Re:It's a race (Score:2, Insightful)
The number of concepts that change in Python 2.0 -> 3.0 is tiny. The main thing that will break everyone's code without the converter is that print changes from a statement to a function, so you need to parentheses everywhere. The rest is removing long-deprecated hacks, making Unicode the default, rearranging the library a bit, making module imports more explicit, and making built-in functions that returned lists instead return iterators, to save memory. All these changes have direct equivalents in the 2.x series. Some concepts are added, too, but that shouldn't be a problem for 2.x code.
This all means that the converter will actually work. For VB, the best they could claim was that 90% of the port would be automatic; for Python's 2to3 conversion tool (included with the installation), it's expected that you can maintain a clean 2.6 codebase and automatically generate 3.0 code as needed until you're ready to switch to 3.0 full-time.
Also, the plan for a backwards-incompatible Python 3.0 has been public for years. As if the incremented major version number wasn't a clue. Why the furor now? I don't recall seeing a story called "KDE4 introduces changes; Earth dying". A release manager made a flippant remark about compatibility, and a tech reporter sniffed blood, that's all.