That is just clearly not true - why do we use insecticides? To stop plants getting eaten by insects. Why? Because that increases yields. Why would we make a plant produce insecticide other than to increase yields? They don't just do it for fun.

You make a good point, but just to be devil's advocate, neither of those are true for Python, where an average is:

sum(data)/len(data)

(In 2.x, there is an integer division error there, but I'm talking 3.x).

You say that you need the backwards compatibility, but you never say why? Why does it make a difference that you are running old code in an old interpreter rather than the new one? Why force new code to be the same as that old code? It's the same thing, only you get the choice to advance.

It's not impossible to upgrade code, and it's always possible to run it in an old (but supported) interpreter. There is no merit to keeping the language at a standstill.

There is a huge difference there - the kernel isn't like Python, you can't run two disparate versions on the same system to run older code.

Programming language have to be able to make occasional breaking changes like this, because otherwise we settle for crap languages with all the problems that can't be fixed. You know what happens then? People make more languages to fill the gap, and then rather than just making a few changes, you either stick with the old bad version (just as you could have before), or switch to a new language which will require a complete rewrite rather than just modification (which, in Python's case, is often as simple as pushing it through 2to3).

If you really can't afford to have Python change, continue to use 2.x - guess what, it's still (as evidenced by this post) being supported, and will be for some time yet.

It's unlikely to happen in the foreseeable future, but ruling it out would be foolhardy - clearly in time the language could be expanded and need alterations.

Of course I understand the importance, but your argument is that there should never be any breaking changes, which means languages have to be perfect from the moment they are made, which is clearly never going to happen. Either we accept a broken language, which is not acceptable, or we make breaking changes. That's necessary sometimes. If you need to, 2.x still exists and you can run something using it.

That doesn't make sense. Of course there is a reason to use Python. I'm not saying PHP being bad makes Python good, I'm using PHP as an example in favour of making breaking changes, as not doing that has caused the language to develop in a way that turns it into a really bad language. As to 'It's only worth it if you can can be sure that you won't have more backwards incompatible changes in the future.' - that makes no sense. Potentially, in the future, the language could have new features added, or features changed to make it better that require breaking backwards compatibility. Naturally, there is always a need to weigh up the cost of doing so with the benefits. I doubt we'll see breaking changes in Python for a long time yet, but they may well happen at some point, and there is nothing wrong with that.

Yes. They do. Again, I use PHP as my example. It's a horrible mess of a language due to the fact they refused to make breaking changes. It's horrific to work with, and virtually impossible to follow good practises with. Loosing backwards compatibility is worth it, when done rarely.

1. Why bother? The language can support it natively, so why not just do that?

2. It should never reach that point - it sounds like your code is convoluted and poorly laid out. If the cost of the function call is actually affecting your program, then the code you are talking about is hugely performance-sensitive, and should probably be offloaded into an extension module.

Except that's simply not true. 3.x is the only time that has happened since the language moved out of it's initial stages.

Why? You just run your old programs in 2.7. Both can be installed at the same time, and there are well-defined ways of indicating which should be used. Sure, there is some cost to not having backwards compatibility, but the gains from improving the language far outweigh those.

That doesn't make it a good idea. Go and look at PHP, and you'll see why. PHP is a horrific mess of deprecated stuff, and it's insanely hard to find the right way to do something in the cruft of hacked in features and old ways of doing things. As with all things, we make mistakes when we design languages. Sometimes, we can fix those without breaking backwards compatibility, sometimes we can't. It's worth making the break to make the language better - it's just not wise to do it more than very rarely.

Wow, really? I've not dealt with C# much, so I can't talk on that front, but I've found Python's docs far more useful than Java's.

Indeed, and for many platforms - I worded my post poorly - I meant to say that unlike py2exe, cx_Freeze works with 3.x as well as 2.x.

If you hate it that much, it'd be trivial to write an application that compiles braces into indentation. The reality is it is more readable, and nicer to write. If you are having problems with whitespace being significant, maybe you should find software that isn't crazy - everything I use handles it fine.