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
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.
Find free books.
&& 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.
if it does, then it will be pointless. I like the whitespace thank you very much.
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
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.
So put #!/usr/bin/python2.6 or whatever in your scripts and don't worry about it for 5 years(probably much longer, due to the significant changes, 2.6 will probably last nearly forever, or at least until basically nobody is using it anywhere).
Or does Ubuntu launch things based on file extensions?
Nerd rage is the funniest rage.
They're just delimited with indentation instead of braces. And it's not the language that is stupid, it's you, because you are apparently not indenting your code at all, or you'd realize that indented code in other languages "Fs up" (you do realize you can say "fuck" on Slashdot, right? Watch: Fuck, fuck, fuck, fuck. It's pretty cool.) stuff just as much as indented Python code does. Any decent editor can automatically indent code for you in any language, and in this case Python is even easier because all it uses is the indentation, so you don't have to manually add additional delimiters in the appropriate places; just indent as usual. Copying and pasting code in any language requires you to reindent it just as much as with Python, lest it become an unreadable mess, and again, any decent editor provides the ability to adjust the indentation of whole blocks of text with ease. And if you find yourself utterly stumped by the challenge of generating properly indented code, you simply should not be programming.
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
You can slam Microsoft for a lot of things, but breaking backwards compatibility (B.C.) would be far, far down on that list. They bend over backwards (no pun intended) to maintain B.C. In fact, that compatibility oftentimes is the source of their security woes. And it is most certainly one of the major causes of code bloat, and buggy code. Personally, I think Microsoft should consider *reducing* their emphasis on B.C. in order to improve those other attributes I mentioned.
The more you regulate a company, the worse its products become.
There's surprisingly little in Python 3.x that's really needed, and much that isn't. The approach to parameter typing (optional and unenforced) is silly. Having it and not enforcing it is just asking for trouble.
It probably would have been more productive to standardize on 2.6 and get a formal standard out the door, instead of using the CPython implementation as the standard. With a formal standard that couldn't be casually changed, the other implementations, all of which are faster than CPython, would have a firm target to implement. Python is twenty years old, and there still aren't multiple, compatible implementations.
Python could be a much higher performance language. Take a look at the Shed Skin implementation. One guy is trying to implement a hard-code compiler for Python that does type inference to determine types at compile time whenever possible. That yields a 10x-30x speedup. If you have rackmount servers running Python, that's a big win - one rack instead of ten.
Python has some optimization gotchas that really should be fixed. The big problem is "undetectable dynamism", or "if the only tool you have is a dictionary, everything looks like a hash". It's rare to store into a local variable of a function, or modify a method of a class from the outside of the class. Most classes don't have attributes added to them after creation. Python allows all these things, which can occasionally be useful. The trouble is that it's really tough to tell at compile time if the hard cases are going to be needed, and thus code has to be pessimized for the worst case.
This could be fixed with a few restrictions:
- Classes which can be dynamically modified from outside themselves should be subclasses of "dynamicobject" instead of "object". This makes everything dynamic but reduces performance. For most objects, the compiler can then find all the variables during
compilation, assign them fixed slots, and avoid having a dictionary in each object.
If an object indulges in self-modification or attribute creation, the compiler can see that at compile time and generate the slow code for the hard case. This is only needed for objects which are patched from outside themselves, something the compiler can't now detect and needs to know about.
- Variables cannot change major type during execution. If a variable is initialized with an integer or float value, it cannot thereafter be changed to an object type. Shed Skin imposes this restriction, which means it doesn't have to "box" numbers in objects and can hard-compile arithmetic.
This would make it possible to boost Python performance up to the Java level, and get it within striking distance of C/C++, yet not require declarations.Why, exactly, is it that it should never have semantic meaning? Is there a rule somewhere?
Guido is following through on the plans he announced years ago! Let's all discuss it as if it were amazingly novel news!
Using two separate mechanisms to denote structure -- curly braces with the real meaning, and indentation as an alleged re-creation of what the curly braces indicate -- also asks for problems. Many people find the whitespace problems less troublesome than the curly-brace problems. Pretending that either solution is perfect is plain nonsense. The Python solution is not hard to use or understand.
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++.
I have seen the future, and it is inconvenient.
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
Python already has C-style string formatting in the form of the % operator.
i.e. print "%03d %03d" % ( num1, num2 )
or, using a hash, print "%(foo)03d %(bar)03d" % { 'foo': num1, 'bar': num2, 'baz': num3 }
So, what exactly is Python missing here, oh wise and mighty smartass C programmer?
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
I mean, am I the only one who's been using Python since at least 1.5.2? The made major changes between that version and 2.0 that broke almost all of our 1.5.2 scripts (particularly in the way they handled regular expressions).
I didn't kill Python then, and it didn't stop us from using 1.5.2 for years to come for our old scripts and 2.x for our newer scripts.
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
and you use && instead of 'and', please try to forget your C background.
Yes, some kind of transition phase is the only approach that makes sense with established APIs. That's precisely why python is doing a 2.6 version to bridge the gap.
Very true, but we do give you the complete source code to all of our older versions. Go crazy.
how to invest, a novice's guide
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.
Calling the new language "Blackadder" is a plan so cunning that if you put a tail on it you could call it a weasel.
I had to port Perl 4 code to Perl 5 and there were some issues.
Your example is quite absurd, since your pretty matrix code is perfect python, up to changing the ; into commas, and adding the missing commas:
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'.
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.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.)
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).
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
If we're breaking compatibility, can we put in requests? The 3 main things I'd like to see are:
1.) Ditch the silly ":" at the end of the line when starting a block. Why on earth is this needed? I almost always forget to use that darn colon.
2.) Ditch the bolted OO on "self" variable for object methods. Just make "self" a keyword and use it the way "this" works in Java/C#/C++.
3.) Allow for a whitespace agnostic mode with the end keyword the way Boo did for goodness sake! Why on earth is that so hard? If you want significant whitespace, it can still be the default. If significant whitespace drives you mad, then use a -wsa switch and a new "end" keyword and be done with it. It would end the flamewars and make Python a more acceptable language to those of us who prefer to have the option of aligning our code the way that makes the most sense, not the way the language Guido thought it should always be.
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.
My problem? I was perfectly gruntled, until some numbnuts came by and dissed me.
The Python 2 to Python 3 transition is not the same as Perl 5 to Perl 6. Perl 6 is a major rethinking of Perl, with a lot of changes. Python 3 is still very similar to Python 2 with very few syntactical changes - the primary motivation for Python 3 to break backwards compatability was to be able to purge implementation cruft from the language that was mostly derived from early design mistakes.
It's true that you'll need to do work to port/test code from Python 2 to Python 3, but learning the syntactical differences can be done in an afternoon, as there aren't that many:
http://docs.python.org/dev/3.0/whatsnew/3.0.html
That's funny. My understanding is that the mods are much more serious than this article lets on. From what I heard they're replacing all the keywords and indentation with some combination of parenthesis, lambda, car and cdr. The language will be SO much improved!
There's no time to stop for gas, we're already late.
the problem is at some point they are going to drop support for it, and no modules will begetting written for it either. the fact that you can maintain it yourself is a retarded response to this, because people who say it have pretty much no idea how much extra work that puts back on you, and frankly no one wants that.
If you mod me down, I will become more powerful than you can imagine....
the problem is at some point they are going to drop support for it
Welcome to software development.
What products don't eventually become unsupported? Even a compiled language like C or C++ has libraries that eventually become unsupported, and maintaining them even if you had the source would become a difficult task.
AccountKiller
To expand on that:
4. Unicode will become the standard throughout Python. This is probably the biggest change. Whereas before the String datatype was synonymous with a byte array (and used for both), it no longer will be. This entails some additional changes in your code to specify the encoding of a String, which will now be represented as Unicode. A new datatype, called "Bytes" (IIRC) can replace the former byte array use of Strings.
5. Many modules in the Standard Library which have been marked deprecated for several versions now (and raised a DeprecationWarning exception) will now actually be removed. Several others with old naming conventions, ambiguous names, or dual Python/C implementations will be renamed, with an appropriate backward-compatible stub that issues the same DeprecationWarning exception, but still works with the old name. A running tally of modules to be removed/renamed is in PEP 3108.
The bottom line is that they are not just making backward-incompatible changes for the sake of changing things. They are specifically trying to avoid "becoming the next Perl 6" to paraphrase Guido from one of his Google Tech Talks. They are just taking this one chance to remove longstanding "warts" from the language in one fell swoop.
Almost everything will be covered by the 2to3 converter. Where required changes are ambiguous, 2to3 will issue a warning and request you fix it manually. I'd rather they fix the problems with the language now before they get any more entrenched. But then, I'm not a maintainer of "legacy" Python code. I am looking forward to the Generic Functions and Adaptation features (among other things) that are being discussed for Python 3000 though.