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.
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
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
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.
Yikes, don't do that. I think its easier to determine which version is newer or older based on the version number associated with it. Who cares about "new" versus "old"? All I care about is whether my/other code will work on a particular interpreter. And figuring that out is harder if interpreter names aren't tied to major language changes. Perl 6 has the advantage of being backwards compatible with Perl 5, despite many changes to the language.
It's called Perl 6, and it's THREE TIMES as almost-here* as Mystery Science Python 3000.
* Parrot, Haskell and Common Lisp
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.
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
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
Why, exactly, is it that it should never have semantic meaning? Is there a rule somewhere?
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.
Ah, I love the python defenders...
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.
Test your net with Netalyzr
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.
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'.
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.
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?
"AndAlso" and "OrElse" are used by other languages such as SML, so it's not like some horrible thing that only Microsoft uses.
-- "I never gave these stories much credence." - HAL 9000
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.
Very interesting. I seem to remember that now that you mention it. But, in line with my original point - VB.NET has changed so drastically from it's ancestor that keeping these obscure vestigial artifacts makes the language feel kludgy. The solitary "End" could have been recommissioned to close the current block, since a standalone "End" has been relegated to obscurity. Perhaps "End Program" would have worked too. I guess it probably doesn't matter and ranks lower than some of the others on my list of annoyances, but this is slashdot - Microsoft gripes abound.
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....