Python 3.0 appears, strangles 2.x compatibility

Slower, doesn't run my old code

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

point-Oh

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.

No more jokes

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.

@yeah, right

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.

@Charles Manning - C compatibility

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

The Full Monty

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.

Crop dusters

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)

Perl 6 and Parrot Roadmaps with release dates..

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

@vincent himpe: Early adopter warnings

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.

@mattk

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.

python speed potential

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.

Why all the fuss

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.

Re: python speed potential

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

An annoying, but useful, hurdle

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.

Only one flavour of Python?

CPython, JPython, IronPython...