Though a bit of reporting fluff on the non-compatibility with 2.x. If a developer hasn't known it or hasn't been taking the proper precautions (assuming they want 3.0 users to run their code), they deserve the complaints. Though there's plenty of help/tools to convert your code and it's not too different anyway.

I'll be upgrading once they address some speed issues, and when it has a good chunk of community uptake; then again, I might just get 2.6 for a while.

So Python 3 runs slower, and my old programs will stop working (maybe) ? Sounds like windows :-)

It's a point-zero version - there are always teething issues. Hope they fix the speed thing though. As for breaking compatibility, I'd say that's a good thing. To improve, it is good to learn from the past, but not necessarily be tied to it.

Since it's open source, support for previous versions can continue indefinitely for anyone who doesn't want to upgrade. Whereas those who need the new features can also move on. There's no company behind the product forcing anyone to switch before they're ready. Best of both worlds really.

Fangs for not making any jokes.

Us grateful readers will remamba you for that.

Very good proof reading, there were no tipan errors.

But...

@yeah right

Sure open source blaah, blaah but in reality loss of compatibility will break the "Batteries included" benefits of python. If you have a lot of old python code and want to extend it with new stuff you're likely going to have to do some porting.

One of the reasons C is quite successful is that even the latest most wizzy versions of C will still compile and work with the most rank and smelly K&R C from when granny was a girl. That might or might not be a good thing.

If they make the language incompatible to previous versions it would have been a sensible thing to add. I should think it is time to admit that garbage collection is not suitable for all kinds of resources, even C++/CLI (the horrible managed language) and PHP (the script kiddie stuff nobody adits to using) have deterministic destructors.

Anonymous, because I don't want anybody to know I'm actually using C++/CLI and PHP...

Python 2.5 is the fastest version of Python. Python 2.6 was released mainly as a forwards compatibility release with 3.0 for library developers. Most code will run unchanged on Python 2.x and 3.x or need only minor changes (print statements to functions, etc.) So the change is nothing like as dramatic as say PHP 4.x to PHP 5.0

Take up at Mountain View is likely to be pretty fast, I would guess. ;-)

I have python2.4 and python2.5 installed at the same time - so I can be sure my code works for customers who have not switched to 2.5. I could support older versions if anybody wanted. 3.0 has been developed in the open where everyone can see what is happening. Switching to 3.0 will be a minor irritation. To use python 3.0, my customers will not have to throw out all their old hardware, buy a pile of expensive computers with power hungry graphics cards, retrain all their staff and modify all their software. Perhaps there is an advantage to free software.

PS: Noddy's guide to programming says one of the most wasteful uses of programmer time is premature optimisation. First get your code working. Emphasise readability far more than efficiency. Delay all thoughts of optimisation until after the program works. Only then, if speed is an issue start profiling to find the places that would benefit from optimisation.

"One of the reasons C is quite successful is that even the latest most wizzy versions of C will still compile and work with the most rank and smelly K&R C from when granny was a girl."

Maybe in theory, but in practice C is one of the least portable languages in modern use. If you've written anything of any significant size you are lucky if it will compile on the same machine with a different compiler. Move it to a different OS and all bets are off.

I'm a C/C++ guy but I have to say, modern languages like Python and Java give you a lot less grief when it comes to compatibility. Python 3.0 might cause you a few porting problems but at least they'll be documented problems - and there's only 1 flavour of Python to worry about.

I'll need to find a day or two to update my Python course materials and the web application I develop for community currency users and then my spam filtering software. The teaching materials are more urgent, while the applications can run fine on 2.6 until 3.x has stabilised a bit and become generally available in stable Linux distribution install packages. Just as well I've got an extensive testing suite for the web application.

I'd rather have to do this kind of upgrade once in a while as a price worth paying for having the language maintain its design purpose. Having a 10% speed hit is neither here nor there if you compare the performance of Python to Ruby on Rails especially on a point zero release.

Pretty much anyone involved with Python has known, well in advance, that 3.0 (or P3k as it was known when I earned a crust as a Python developer) would more than likely break old code - ISTR that this was one of the first things that GvR said when all the 3.0 stuff was announced. I also remember it being mentioned that there would be tools to ease the transition between 2.x and 3.0 but that complex applications would need extra work.

So, all common sense as far as I can see.

But, whither Perl 6? If you have to asp, you don't want to know (obligatory snake joke - d'you see what I did there?)

I only do a little bit of simple Python programming but I think the 'print' function looks a little odd with keywords in it instead of positional values. I know it's to add lots of functionality to it and that wouldn't be possible with positional values. I like the 'with' statement and have got used to using it. It does not look odd but the 'print' function does.

GNU utils (for Windows) + Python has pretty much replaced GNU utils + QuickBasic for my quick and dirty text file manipulation needs.

Hey, El Reg, it looks like you got the Ouroboros piccy from the Medway Crop Circle site. I would have expected you to harvest pictures from a better quality of site than that. Anyway, they reckon it means all matter will move from the third dimension to the fifth, soon, maybe. I wonder if the new 'print' function can help?

print(all_matter, fromD=3, toD=5)

<i>

One of the reasons C is quite successful is that even the latest most wizzy versions of C will still compile and work with the most rank and smelly K&R C from when granny was a girl.

</i>

Not on Microsoft Visual C it won't! Just Try to build the Windows distribution of Python on *anything else* than the EggAcct version of Visual C and you will die of boredom before you have fixed the hundreds of compile errors.

In answer to the inevitable (and probably just trolling) question :

Parrot 1.0 release is likely to be March 2009 (just a couple of months away)

Perl 6 on Parrot 1.0 release is likely to be in Q1 of 2010 with release candidates late in 2009

Unlike Python 3, this is a major update, I don't think Python 3 vs Python 2.x is a large step, and significantly smaller than the changes from PHP 3 to 4 to 5, or Perl 4 to 5, it's not even much more than the changes between say Perl 5.4 and 5.6, 5.8 or 5.10 (all of which added new syntax, features and some fairly big changes)

more details at :

http://perlbuzz.com/2008/11/parrot-10-will-be-out-in-march-2009.html#comments

It's slower and breaks exisiting code. Sounds almost like Vista ....

Mine's the one with the Visual Basic CD in the pocket...

There are a couple of comments that 3.0 is slower, and this is well known (http://jessenoller.com/2008/12/04/python-30-some-multiprocessing-info-administrative-notes/).

3.0 is also widely known (if you have been paying attention), to break existing code, a necessary cost to allow the language to evolve. This is in direct contrast to Microsoft, who are also well known to produce software with many, many compromises to maintain backward compatibility (and problems).

Immediately moving to 3.0 is something that not everyone (or most) should do right away, but as mentioned in the above line, use it as part of a migration strategy.

In all, I can't think of a strategy that is less Microsoft like.

i was making a pun. when MS migrated from VB6 to .NEt they also broke tons of existing stuff. Same with vista: it was supposed to be faster . turned out to be slower and a resource hog. Many 'XP' programs experience trouble when running on vista.

Anyway. Not my problem. I don't use python. I tried it. I didn't like the forced 'indentation' it has. don;t know if that is still so in 3.0. also the lack of good editor ( read an editor that fixes my typos like missing brackets and semicolons. I like the intellisense in visual studio. ) but again. that was like 2 years ago.

Most of the comments are from the developer's point of view. I don't know Python, and I don't want to learn it. My typical scenario is that I download a tar file of a chemical visualisation program (there are several written in Python) that a couple of grad students wrote five years ago. That today's developers of different codes "saw it coming" doesn't help me one bit!

In my experience, already 2.2/3/4 were not really compatible.

I wonder how fast it will be possible to make dynamic languages? Neither Sun nor MS has been able to get dynamic language to run on their respective Java and .NET VMs. I think most people who want a fast dynamic language, such as in game scripting, use Lua. But I think their are faster dynamic language than that such as Pike and Squirrel. But if Python and Ruby could run as fast as Java, then that could really expand the use of scripting languages and blur the line between interpreted and compiled language use.

To break compatibility. This usually raises a chorus of complaints from the users...

On the other hand, it's the moment or never for me to finally learn it!

Over noncompiled languages(this includes Java and the .NET ripoffs)? I understand that some areas require the speed less than the ability to make quick changes(Java has the worst of both worlds in this area), but why does there seem to be a belief that they can actually replace full languages? Wake me up when somebody introduces a good real language that isn't a ripoff of something nearly half a century old.

"wonder how fast it will be possible to make dynamic languages?"

If the code is well-written, something written in a dynamic language can be very fast indeed - in a previous job I inherited a bunch of Python code which did, amongst other things, numerical simulations. By rewriting and *simplifying* certain areas of the code, significant speed improvements were had without resorting to writing modules in C or, *shudder*, FORTRAN (here's a tip - if you want to kill performance, use map() and reduce() where simple population of an array in a for() loop would do - sometimes being a smartarse isn't the best way of doing things)

Python has also been used in game scripting - Civilization 4 is probably the best-known example.

Getting an interpreted language to run as fast as Java might take some doing - look how long its taken Java to get to its current performance state, for example. That said, I'll be watching the development of Parrot and Perl 6 with interest, as there's plenty of potential there.

Remember the 640K limits of DOS and how they plagued PCs well after systems were available with MBytes of RAM? Or how PRINTs to Windows consoles are still very slow in the age of super-fast GPUs? Remember wishing they would just fix it and damn 10 year old codelines rather than forcing everyone to live with bad decisions forever?

I don't think Python has any such obviously dim features built into it, but over the 15 or so years it has been around, many little quirks have accumulated and are a hassle. Python 3.x is meant as a clean up to facilitate working with the language for the next decade(s).

For example, I've always thought Python is great to discover new problem domains. But Python 2.x and Unicode is not exactly ideal and I still don't grok Unicode at low levels. If 3.0 really brings easy Unicode, I am well willing to deal with upgrade hassles.

Google "Let’s talk about Python 3.0" and you'll see a much better argued, and quite entertaining, version of my argument. Love the banana and monkeys story!

I am pretty much each change has been discussed extensively to weigh the benefit vs. the cost and the designers are _extremely_ anal about keeping the language as easy as possible to understand. I trust them. And if they were wrong, Python 2.6+ will be around for a long time.

Besides the regression testing workload, I think the biggest risk is when you depend on multiple non-core 3rd party libraries that move, or do not move, to 3.+. And, for the folks concerned about the 10% penalty, just relax and wait a more-optimized Python 3.1, it'll come. Get it right, then speed it up. Basic Knuth.

Even M$ damned the torpedoes and broke some compatibility with Vista. Oh, wait, that's not exactly proving my point, is it?

p.s. This story's title is just a wee bit sensationalist and alarmist, IMHO. But txs for the publicity nevertheless.

CPython, JPython, IronPython...