Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Python 3.0 To Be Backwards Incompatible

kdawson posted more than 6 years ago | from the it's-broke-jim dept.

Software 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."

cancel ×

438 comments

Sorry! There are no comments related to the filter you selected.

It's a race (5, Insightful)

Intron (870560) | more than 6 years ago | (#22263270)

Will the new Perl or the new Python be the first to shoot itself in the foot with incompatibility?

Goatse to be backwards compatible (-1, Troll)

Anonymous Coward | more than 6 years ago | (#22263312)

...or "behinds" compatible, lol...
Click here. It doesn't work anymore. ;) [goatse.cx]

Re:It's a race (1)

simcop2387 (703011) | more than 6 years ago | (#22263622)

Python apparantly, Perl6 is backwards compatible with Perl5 even though it has many new features

Re:It's a race (1)

drolli (522659) | more than 6 years ago | (#22263716)

And i think perl 5 was compatible to perl 4 (AFAIR). Just adding things...
I really dont want to know ho perl will look in 20 years....

Re:It's a race (3, Informative)

Anonymous Coward | more than 6 years ago | (#22263850)

Is Perl 6 backward-compatible with Perl 5?
No. [programmersheaven.com]

Re:It's a race (1, Interesting)

misleb (129952) | more than 6 years ago | (#22263766)

While both Perl and Python are in need of a fat trimming in terms of obsolete and redundant language features, I think Python has a small enough user base that they could actually pull it off.

Re:It's a race (1, Redundant)

FuzzyDaddy (584528) | more than 6 years ago | (#22263960)

15% of the google codebase consitutes a "small user base"?

Re:It's a race (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#22264060)

Python, obviously. The perl fucktards are years away from releasing anything that anyone cares about.

Just rename it. (5, Interesting)

Besna (1175279) | more than 6 years ago | (#22263278)

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

Re:Just rename it. (5, Funny)

Neil Hodges (960909) | more than 6 years ago | (#22263342)

There are already other [wikipedia.org] languages [wikipedia.org] doing this. If you think naming closely-related languages the same thing is a kludge, what do you think of naming mostly-unrelated languages the same thing?

Re:Just rename it. (1)

BigJClark (1226554) | more than 6 years ago | (#22263480)


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.

Otherwise, we'll be left with Python 1, Python 2, Cobra 1, Cobra 1.1, Cobra 1.3, Rattlesnake A, Rattlesnake SP1, Diamondback etc etc

I realise its boring, but please, think of the children.

Re:Just rename it. (2, Insightful)

workdeville (1166127) | more than 6 years ago | (#22263778)

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.

Re:Just rename it. (3, Funny)

Anonymous Coward | more than 6 years ago | (#22263970)

> Otherwise, we'll be left with Python 1, Python 2, Cobra 1, Cobra 1.1, Cobra 1.3, Rattlesnake A, Rattlesnake SP1, Diamondback etc etc

"THAT'S IT! I have had it with these muthafuckin' snakes on the covers of these muthafuckin' O'Reilly books!"
- Guido L. Jackson.

Re:Just rename it. (1)

anno1602 (320047) | more than 6 years ago | (#22263998)

You forgot "Black Mamba" (SCNR)

Re:Just rename it. (2, Informative)

BrunoUsesBBEdit (636379) | more than 6 years ago | (#22264084)

Yikes don't do that because the choice of the name Python has nothing to do with Serpentes [wikipedia.org] . It was chosen because of Monty Python's Flying Circus [wikipedia.org] . So, the associations would be more like: Chapman, Idle, Gilliam, Jones, Cleese, Palin. Or it could be other comedy teams like: Mad, Saturday, Color, Hall, State, etc.

Further more, if you don't already know that, why are you posting?

Re:Just rename it. (5, Informative)

Bogtha (906264) | more than 6 years ago | (#22263558)

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.

Damn right (0)

Anonymous Coward | more than 6 years ago | (#22263588)

The reason I use Python is that I used to use Visual Basic and Microsoft borked me by creating a backwards incompatible version (somewhere around ver. 2 iirc). I have written a lot of python script. The idea of having to fix it all ... it ain't going to happen.

If they change the extension, we can still use our old code with an old installed version of Python. What worries me is that Ubuntu does all these updates. That means that someday, without warning, my Python scripts won't work any more.

Re:Damn right (2, Informative)

maxume (22995) | more than 6 years ago | (#22263668)

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?

Re:Damn right (1)

SQLGuru (980662) | more than 6 years ago | (#22263974)

I know in Windows you can associate an extension any way you want, so I asssume Linux can too......just make your own extension (.py26) and associate it with the older install of Python. A quick little shell script should go through and rename all of the files and *then*, when Python gets updated or when you get a script from someone else, you don't have to worry about it.....your stuff should continue to hummm along until you get around to fixing the incompatibilities (or someone writes a program to fix it for you).

Layne

Re:Just rename it. (1)

sumdumass (711423) | more than 6 years ago | (#22263694)

I agree that if it is so incompatible it should have a name change. But I might suggest something a little less obvious like Python.three instead of using the three as a 3 versioning number.

I hear the changes aren't supposed to be that drastic but then again, I have to wonder why the heads up if that was the case. Maybe as it gets closer, we will see that it is stuff so obscure that it won't bother 99% of everyone.

Re:Just rename it. (4, Funny)

Speare (84249) | more than 6 years ago | (#22263818)

Python's named after the troupe Monty Python, not after the snake species. I don't think renaming it is a good idea, but suitable successors would be [Life of] Brian, [Fish Called] Wanda, Flying Circus, Holy Grail or perhaps start with sub-versions like Cleese, Chapman and Palin.

Alternatively, pick another troupe or favorite comedy show: Fry and Laurie, Mr. Bean, Fawlty Towers or Red Dwarf. Or my favorite, which brings back in the snake species AND British comedy into circular pun, Blackadder.

While talking about puns, snakes and coming full circle, I suggest Ouroboros.

Another Shock Story (5, Informative)

LowSNR (1138511) | more than 6 years ago | (#22263292)

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 (4, Interesting)

betterunixthanunix (980855) | more than 6 years ago | (#22263504)

No, but that means that everyone planning to run non-Python3 code will have to maintain two parallel Python installations. With package management that's not so bad, but it still puts a bit of pain on distro maintainers.

Yet everyone makes fun of me when I say that I am a C++ programmer.

Re:Another Shock Story (2, Funny)

Schraegstrichpunkt (931443) | more than 6 years ago | (#22263682)

No, but that means that everyone planning to run non-Python3 code will have to maintain two parallel Python installations. With package management that's not so bad, but it still puts a bit of pain on distro maintainers.

This is already done in the distros I've seen.

Re:Another Shock Story (1, Informative)

Anonymous Coward | more than 6 years ago | (#22263696)

This is just not true. There will be a utility included with py3k that converts most purely syntactical differences from py2.x code into compatible running py 3.0 code. The official word on this is that the recommended upgrade path is to maintain your codebase as 2.x code that can also be converted into python 3.0 code in a completely automated way (that is, keep it compliant with py 2.6, but change things so that the automater script can generate py 3.0 code). When backwards compatability is no longer needed you can convert to the 3.0 codebase.

If anything its a long term upgrade path, not some "OMG EVERYTHING WILL BREAK NEXT YEAR" type crisis.

Re:Another Shock Story (0)

Anonymous Coward | more than 6 years ago | (#22263892)

Not true. You will be able to write 2.6 code that will be machine-translatable to 3.0, using a supplied tool (2to3). There will be no need to maintain two code bases.

Re:Another Shock Story (1)

MrLizardo (264289) | more than 6 years ago | (#22263968)

First of all, the framework already exists in Debian (and I'm sure RedHat-based distros...) to have two versions of Python installed. This is not rocket science. And before you gloat too much about C++, having two versions of g++ installed has been a fairly constant experience for many Linux users as well. This is totally a non-issue and will make no difference to package maintainers...

Re:Another Shock Story (5, Interesting)

onion2k (203094) | more than 6 years ago | (#22263548)

It is an issue though. PHP did exactly the same between version 4 and 5, and it crippled adoption of 5 because hosts refused to upgrade as it'd have broken too much code. It was a full 3 years or so before 5 was really considered the primary version amongst many developers and that took the announcement of 4.x support ending and the success of the GoPHP5 campaign.

Hopefully the Python team will learn from PHP's experience.

Re:Another Shock Story (2, Insightful)

misleb (129952) | more than 6 years ago | (#22264086)

It is an issue though. PHP did exactly the same between version 4 and 5, and it crippled adoption of 5 because hosts refused to upgrade as it'd have broken too much code


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:Another Shock Story (1)

Eco-Mono (978899) | more than 6 years ago | (#22263576)

Especially since, y'know, the plan to let Python 3000 be backwards-incompatible has been in place for at least two years now.

*shrug*

Re:Another Shock Story (2, Informative)

Bogtha (906264) | more than 6 years ago | (#22264026)

It's been a lot longer than two years. For example, see this thread [google.com] from eight years ago:

The new release schedule provides for a 1.7 release later in 2000 (or early 2001); after that, we'll be working on "Python 3000" (the new code name for the grand Python redesign; the language will be incompatible).

And from a reply:

(personally, I'd be very surprised if the changes were such that old code couldn't be automatically translated).

Re:Another Shock Story (1)

LWATCDR (28044) | more than 6 years ago | (#22263984)

It is an issue for new projects.
If you are going to start a project today do you use python 2.x or wait for python 3.x?
Someday one of them well go bye bye and somebody will have to fix the problems that causes.
What if you are going to embed python into an application as a macro language?
No the sky isn't falling. The sky never rarely does fall. But it is an issue.

Workaround... (5, Funny)

fahrbot-bot (874524) | more than 6 years ago | (#22263328)

I think I have a Perl script that'll fix this...

Just kidding Python fanbois :-)
Chill, it's Friday.

Re:Workaround... (5, Informative)

tuffy (10202) | more than 6 years ago | (#22263438)

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.

Re:Workaround... (1)

Crazy Man on Fire (153457) | more than 6 years ago | (#22263586)

Actually, the article says that 2.6 and 3.0 will be released around the same time:

The Python development community was committed to providing a smooth upgrade path and will build a number of forwards-compatible new features into the next release of the current version of the language, version 2.6. This release is expected to come out around the same time as the release of 3.0, said Baxter.

Use (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#22263366)

Lisp

Re:Use (0)

Anonymous Coward | more than 6 years ago | (#22263680)

Good idea. It hasn't changed in 80 years.

Re:Use (1, Insightful)

Anonymous Coward | more than 6 years ago | (#22263876)

It's called Perl 6, and it's THREE TIMES as almost-here* as Mystery Science Python 3000.

* Parrot, Haskell and Common Lisp

Solid technical reasons (0)

Anonymous Coward | more than 6 years ago | (#22263374)

It has something to do with the fact that the fangs curve backwards.

print as function vs. keyword (5, Informative)

spookymonster (238226) | more than 6 years ago | (#22263376)

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 (4, Informative)

Bogtha (906264) | more than 6 years ago | (#22263636)

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:print as function vs. keyword (3, Interesting)

Wiseman1024 (993899) | more than 6 years ago | (#22263718)

A good one though. Statements are stupid. Probably Python's biggest flaw. It's good that they're getting rid of a couple of them, though while, if and the like still remain.

If you're wondering why statements are stupid: they are not first class values you can pass, use and manipulate; they introduce a special, harder to learn and very quirky syntax; they cannot be used anywhere and thus subtract flexibility; and they are an extra form or feature that's actually unnecessary ("Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary." - R6RS, Introduction, best piece of insight on software design ever).

The difference between print >>lol, wtf and print(wtf, file=lol) is that, in the later case, print is a first-class value (a function, in this case) that I can pass to another function should I need it to call it back, or use in the middle of an expression.

I don't see the problem (5, Insightful)

Urger (817972) | more than 6 years ago | (#22263380)

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.

We have options. (4, Insightful)

Sludge (1234) | more than 6 years ago | (#22263388)

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.

Re:We have options. (0)

Anonymous Coward | more than 6 years ago | (#22264074)

Exactly. I remember a lot of hosts still allowing you to run your PHP through version 3 instead of version 4 years ago. Just as right now most hosts allow you to still run your PHP through version 4 instead of 5.

This is news, yes, but not the sensationalistic drama people are making it out to be. In the end Python3 is probably heading in the right direction and they probably couldn't have done this without breaking compatibility.

#1 way to prevent adoption of new language version (0, Flamebait)

mmeister (862972) | more than 6 years ago | (#22263394)

This looks like a shoot yourself in the foot moment. I briefly read through the Py3K stuff and found it difficult to see what the true benefits were for creating this incompatibility. If they want to do this and have folks adopt it, they need to provide a COMPELLING SET OF REASONS for why they are making it incompatible.

If you're going to make a language completely incompatible, you basically have created a NEW language.

Re:#1 way to prevent adoption of new language vers (4, Informative)

Llywelyn (531070) | more than 6 years ago | (#22263918)

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.

Whiners (5, Insightful)

MikeDataLink (536925) | more than 6 years ago | (#22263408)

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

Re:Whiners (3, Funny)

Sciros (986030) | more than 6 years ago | (#22263496)

What color?

Re:Whiners (2, Insightful)

sayfawa (1099071) | more than 6 years ago | (#22263652)

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?


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.

Re:Whiners (0)

Anonymous Coward | more than 6 years ago | (#22263928)

"Tell, me exactly what would satisfy you?"

Ok, I tell: you exactly not satisfy me at all!

(Sorry, my brain told my fingers to stop typing, and they wouldn't.)

Re:Whiners (5, Funny)

19thNervousBreakdown (768619) | more than 6 years ago | (#22264022)

It's almost like there's more than one person with an opinion on this!

Sad day (0, Troll)

DJ Jones (997846) | more than 6 years ago | (#22263410)

They really went the Microsoft route on this one.

The Microsoft route (4, Insightful)

mariox19 (632969) | more than 6 years ago | (#22263654)

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:Sad day (2, Insightful)

LaughingCoder (914424) | more than 6 years ago | (#22263978)

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.

meh (4, Insightful)

seanyboy (587819) | more than 6 years ago | (#22263412)

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.

in fact, such a utility already exists (5, Informative)

Reality Master 201 (578873) | more than 6 years ago | (#22263524)

http://svn.python.org/view/sandbox/trunk/2to3/ [python.org]

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.

15 lines? (0)

Anonymous Coward | more than 6 years ago | (#22263884)

...or you could do that with a Perl oneliner ;)

Provided you've got a wide terminal, of course.

Sounds interesting (1)

JoeCommodore (567479) | more than 6 years ago | (#22263414)

Sounds like they are definitely going for a version 3 of the language. They have identified what they need to fix and add to version 2 and are going to implement it in version 3. I have messed with python so I don't have a heavy code investment in it yet but either way - if it makes Python better than it is, I think its worth considering.

So, will it FINALLY have block structures? (-1, Flamebait)

nweaver (113078) | more than 6 years ago | (#22263418)

Instead of the stupid "whitespace has semantic meaning", which Fs up editors, cut & paste, and code generators?

Re:So, will it FINALLY have block structures? (2)

pembo13 (770295) | more than 6 years ago | (#22263554)

if it does, then it will be pointless. I like the whitespace thank you very much.

Re:So, will it FINALLY have block structures? (1)

Surt (22457) | more than 6 years ago | (#22263616)

No, sadly, they aren't fixing any of the key problems with the language, they're just not maintaining compatibility. Should be pretty much the death knell for python. I guess ruby wins.

Re:So, will it FINALLY have block structures? (1)

timster (32400) | more than 6 years ago | (#22263624)

Are you doing serious programming in Python with an editor that doesn't understand Python's block style? For that matter, when you do copy/paste with your C++ code, are you saying you don't bother to fix the indentation?

Re:So, will it FINALLY have block structures? (1)

nweaver (113078) | more than 6 years ago | (#22263686)

I'm saying the editor fixes the indentation for you.

Have you ever used LISP? The editor reads the parenthesis, you read the indentation.

Indentation is a derived piece of structure, but should never have semantic meaning in a language except as a separator. Anytime you do so you ask for problems, both for editors, for code generators, and for users.

Re:So, will it FINALLY have block structures? (1)

Hatta (162192) | more than 6 years ago | (#22263768)

You can have C code auto-indent with no problems, because even if it does it wrong it doesn't matter. Since Python's whitespace is semantic auto-indent would change the meaning of the code, which should never ever happen.

White semantics make plenty of sense, young buck (1)

TheCouchPotatoFamine (628797) | more than 6 years ago | (#22263710)

(young buck, slashdot id's not withstanding :))

Whitespace Scoping and Block Scoping are two end of a dichotomy. Before you go wishin' it wasn't this way, well, i'm not going to belabor it but some of us like to actually be able to scan code without having to inspect every darn character to figure out where things start and end. It actually takes brain cycles to do that that could be spent on comprehension instead of syntactical flukery. It's a psychology thing not unlike the HID guideline (hid? in code? you betcha!)

If you doubt still, perhaps this will sate you instead: it is a five line perl script (i misplaced it) to convert whitespace indenting to block indenting. They ARE identical and can be translated between freely. Whitespace indented perl? You Betcha!! "Curly" python? Sure! If it bothers you, go write that script and get outta da way :)

best, and truthfully!

Re:White semantics make plenty of sense, young buc (1)

Hatta (162192) | more than 6 years ago | (#22263810)

Whitespace indented perl? You Betcha!! "Curly" python? Sure! If it bothers you, go write that script and get outta da way :)

Really? I can write python without thinking about indentation and whitespace, run it through an auto-indenter when I'm done and have it work correctly? How?

It does have block statements. (2, Funny)

Virak (897071) | more than 6 years ago | (#22263726)

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.

Re:It does have block statements. (1)

adisakp (705706) | more than 6 years ago | (#22263872)

you do realize you can say "fuck" on Slashdot, right? Watch: Fuck, fuck, fuck, fuck. It's pretty cool

Depends on who has mod points that day. I once got modded down to "-1 flamebait" for pointing out that RTFM means "Read The Fucking Manual" as opposed to "Read The Fine Manual" which appeared in a linked article. I'm sure if the creators of RTFM thought the manual was "fine", they'd be saying RTFFM anyhow :)

Re:It does have block statements. (2, Interesting)

Fweeky (41046) | more than 6 years ago | (#22263994)

Copying and pasting code in any language requires you to reindent it just as much as with Python, lest it become an unreadable mess,
Except with delimiters I can just type gg=G and I'm pretty much done.

So long... (1)

corychristison (951993) | more than 6 years ago | (#22263426)

... as I can have them installed side-by-side. Perhaps make the executable python3 or something to use different shebang lines (#!/usr/bin/python and #!/usr/bin/python3). If I recall correctly most OS's use a symlink python to the version anyway.

Would make the transition easier for everybody. My OS of choice (Gentoo) uses Python as the distribution method.

Version 3.0 of EVERYTHING should be rewritten (1)

$RANDOMLUSER (804576) | more than 6 years ago | (#22263432)

I applaud these guys for having the balls to say "I'm going to take what I've learned from the mistakes I made in versions 1 and 2, and start over with something better". I love Java, but I sure wish some of the 1.1 and 1.2 cruft would go away.

Python is doomed (5, Funny)

Arthur B. (806360) | more than 6 years ago | (#22263442)

Look at C++, they broke backwards compatibility with C ( malloc casting for example ) and because of that it never became mainstream.

Re:Python is doomed (0)

Anonymous Coward | more than 6 years ago | (#22263740)

C++ isn't mainstream? Where have you been the last 10 years? Tons of code is written in C++ including large parts of Windows, Qt and wxPython to mention a few. If it has to be fast and maintainable you use C++.

Re:Python is doomed (1)

cbart387 (1192883) | more than 6 years ago | (#22263834)

I was under the distinct impression that what you write in C can be compiled as C++. Can you give a specific example of where this isn't the case?

Re:Python is doomed (1)

cbart387 (1192883) | more than 6 years ago | (#22263870)

Sorry, I should say that you can link object files (from C) and call C functions from C++. I'm not aware of you can compile C as C++ 100%.

Re:Python is doomed (1)

itsdapead (734413) | more than 6 years ago | (#22264088)

Look at C++, they broke backwards compatibility with C ( malloc casting for example ) and because of that it never became mainstream.

Two differences:

  1. C++ ain't C version 2. is a new language that happened to have some backwards compatibility with C.
  2. C/C++ is (...er, reads point one..) ^H^H are compiled language! Practical upshot: if you install a C++ compiler it won't instantly stop all C-derived binaries on your system from working; and you don't have to persuade your users to install C++ in order to run your latest code.

So does Python 3 also sacrifice backward compatibility with Makefile and FORTRAN, or does it still use whitespace as syntax? :->

Almost 2 years old? (5, Informative)

Anonymous Coward | more than 6 years ago | (#22263446)

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

Python Version Hell (1)

Doc Ruby (173196) | more than 6 years ago | (#22263458)

Last year, both Ubuntu upgrades (from 0610 to 0704 and then to 0710) each sent me into Python version mishmash/compatibility hell. But at least they could be mixed together a little, to bootstrap back to a working installation.

I wish these scripting languages were really just APIs, and could all be compiled to binary code instead of depending on different versions of different interpreters. The script source is just too transient without needing to be when working under the hood.

Re:Python Version Hell (1)

nuzak (959558) | more than 6 years ago | (#22263562)

> I wish these scripting languages were really just APIs, and could all be compiled to binary code instead of depending on different versions of different interpreters.

So basically, you're looking for .NET or Java or Parrot then. All three of 'em do run Python. Of course each of those is itself an interpreter...

Python3000 had some pretty grand visions. Optional static typing. Generic functions. Look what we got: meaningless type annotations on functions, not even on locals. "Abstract Base Classes" which are similarly meaningless mixins and barely qualify as roles/traits. Oh yeah, print is a function now, and unicode is the default string type. Whoop de freakin do. I guess the incompatibilities warrant a major version bump, but it's a singularly unimpressive feature set for a modern language.

Re:Python Version Hell (1)

Doc Ruby (173196) | more than 6 years ago | (#22263698)

How do I eliminate all the Python VMs and libraries from my system to instead run the Python scripts against only my single Perl installation? Even if I have to install a bunch of Perl modules to do it.

But to really do waht I want, I'd need to actually compile those Python scripts in with the Perl executables, which I thought was too hard with autoloading and other dynamic runtime execution.

The Perl scripts can stay interpreted. They've never caused me any version trouble yet. Though I wish every CPAN download were available through APT in a .deb package, instead of (perl -MCPAN) .

Well... (0)

Anonymous Coward | more than 6 years ago | (#22263482)

This was bound to happen eventually. Legacy compatibility eventually becomes too cumbersome to maintain along with the new standard. This happens in all areas of technology, something new and better comes along, and eventually, the old tech is replaced. Backwards compatibility is nice, but not every developer wants to maintain compatibility with old standards.

Following Microsoft's example? (1)

bogaboga (793279) | more than 6 years ago | (#22263498)

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.

I'd like to hear from slashdotters who used to blame Microsoft when Microsoft release software that broke backwards compatibility with existing versions. Is Python's development team following Microsoft's lead here?

Re:Following Microsoft's example? (1)

644bd346996 (1012333) | more than 6 years ago | (#22263744)

Is Python's development team following Microsoft's lead here?
No. When creating new platforms, it is inevitable that nobody will get it right on the first try, and that flaws will be found as people try to do new things with it. The similarities stop there. Microsoft frequently doesn't even try to fix fundamental design flaws until after they release the software into the wild and let it fester for a few years. Python, on the other hand, was designed from the start to be a readable and easy to use language, and evidently with considerably more care than many of Microsoft's more notorious kludges. It's a trade-off for sure, but obviously one that appeals to most hacker types.

Not news in any way (4, Informative)

Bogtha (906264) | more than 6 years ago | (#22263510)

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 [python.org] , 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 [python.org] .

Re:Not news in any way (1)

Wiseman1024 (993899) | more than 6 years ago | (#22263756)

Finally, somebody realized this article is !news .

philosophy (2, Insightful)

bcrowell (177657) | more than 6 years ago | (#22263512)

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 (4, Insightful)

pembo13 (770295) | more than 6 years ago | (#22263522)

&& you use python, please turn in your developer card

All for it. (1)

misleb (129952) | more than 6 years ago | (#22263564)

While I'm not much of a Python programmer, it is refreshing to see projects are are not afraid to risk breaking compatibility in the name of progress and getting rid of legacy cruft. One thing I noticed about Python the few times I tried it was that there seemed to be a lot of ways (many of them officially "obsolete") of doing the same thing. One bit of confusion I recall is trying to call the "super" method of a parent class when you've overridden a method. In my research I found several long articles about the pros and cons of different ways of doing it and I just got more confused.

Compatibility is often overvalued and tends to add needless complexity and bloat. Just look at Windows.

Re:All for it. (0)

Anonymous Coward | more than 6 years ago | (#22264076)

quite right, you let your stuff stagnate and you end up with a bloated mess. I really hate that I have to mention Windows here, but look at OSX Leopard? Can you even use OS9 stuff any more? Then look at vista, which runs SimCity95 natively, but at what cost! i'll do myself the favor of posting anonymously because I know full well this has been said 9 or 10 times already.

Old news (1)

Yvanhoe (564877) | more than 6 years ago | (#22263590)

Python 3000 (the draft for Python 3) has been in the works since 2006 and it has quickly been made quite clear that backward compatibility would be broken.

Well I guess old news is better than no news at all...

So python is now dead? (1)

guysmilee (720583) | more than 6 years ago | (#22263598)

Why would anyone consider even using python for the next few years ... sounds like someone just killed python to me!

Re:So python is now dead? (0)

Anonymous Coward | more than 6 years ago | (#22263798)

Yes, you stop using Python, and we'll let you know when it is safe again.

Re:So python is now dead? (1)

Marcion (876801) | more than 6 years ago | (#22263860)

There is a clear and well defined path. Continue to write code against the two series (2.5, 2.6, and so on) until the whole world has moved to 3.0.

During this time, an automated tool will provide a 3.0 version of your 2.6 code. Don't edit the 3.0 code but instead keep adding the changes to the 2.6 version and regenerate the 3.0 code.

Re:So python is now dead? (0)

Anonymous Coward | more than 6 years ago | (#22264018)

Since you obviously don't use Python now (this wouldn't be news if you did), what difference does it make if it's dead to you?

Great timing! (1)

somegeekynick (1011759) | more than 6 years ago | (#22263772)

A couple of tabs away, I have the Python Docs/Tutorial page open learning about keyword arguments. Would have I to learn everything over again in a year?

It's not just incompatible... (1)

ameline (771895) | more than 6 years ago | (#22263858)

It's not just incompatible -- it's also 33% slower.

And if you order today, you'll also get a nice pile of shiny new bugs for only the cost of shipping and handling.
Don't wait! Call now!
The first 100 callers will also receive a free kick to the testicles.

Smoothing out the wrinkles (1)

steveha (103154) | more than 6 years ago | (#22263952)

Python is already a very smooth language, but there are a few corners where it could be better. The Python guys are taking this chance to smooth out the wrinkles.

For example, Python 2.x has both range() and xrange(), and the only difference is that range() actually builds a list and xrange() doesn't (it returns an iterable object that can be expanded into a list if you like, or just used in a for loop or whatever). There is no real need to have both range() and xrange(), so Python 3.x will simply have range() and it will return an iterator. More generally, all the Python features that return a list in 2.x will now return an iterator, and the special variants that return iterators will vanish.

There are many other changes but that one is representative. There is nothing here as dramatic as the changes from Perl 5 to Perl 6. Also, there is a nifty automated tool to help migrate Python 2.6 programs to Python 3.0 programs. There is no huge controversy here, sensational headlines notwithstanding.

I predict that the Python community will embrace Python 3.x when it's available. Python 2.x won't vanish instantly, but people will want to migrate to the new Python, and certainly schools using Python to teach will want to start using Python 3.0 immediately.

steveha

Python takes a step backwards. (2, Informative)

Animats (122034) | more than 6 years ago | (#22264072)

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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>