Python 3 - what were they thinking?

I'm a huge fan of Python for all kinds of programming, just about anything that doesn't need high performance or huge data structures. At my new company we are using it for all kinds of things. It's because I like Python so much that I'm so mad at the core team for forcing the Python 3 do-I-or-don't-I dilemma on the world (and more specifically, on me). I was forced this week to make the company-wide decision as to which dialect to use. There's no really good answer, though in the end I decided on Python 2 rather than Python 3.

What makes me angry is that the need to choose was forced upon the world by the sheer arrogance of the Python team. There's absolutely nothing in Python 3 that couldn't have been done in a backward-compatible way, allowing a gradual migration. Instead, they chose to make numerous changes which make it impossible to write code which will compile either as V2 or V3 of the language.

If you're just writing your own code, you can of course choose either version. But the big advantage of Python is the vast number of libraries for doing just about anything you can think of. And if you want to use those, they have to be available in your chosen dialect. According to a blog I read, less than a quarter of all libraries have been converted, including some major ones such as Django, which presents databases as web pages. Or if they have been converted, the paint is still very wet on the conversion and there are likely to be performance issues or just plain bugs. Another blog started out by promoting the idea of using V3, but ended up by saying that if it's for serious production, you're better off staying with V2. As it happens we don't need Djano, matplotlib, or numpy (three of the biggest libraries), but you never know what's round the corner, or what nifty library you'd like to use but can't because its developers haven't made the effort to do the porting - and after all, why should they, given that much of this code is written by volunteers, for fun.

Yes, there is one fundamental change which it would be hard to do in a compatible way, which has to do with the representation of strings. But for most uses of the language, this doesn't really matter. Only if you deal with transformations between raw bytes and strings do you really need to be exposed to this. There would certainly be a way, using the "future" concept, to allow the minority of code that needs to know about this to deal with it in a compatible way.

All of the other changes are just change for change's sake. Yes, maybe the new form is better in some ivory-tower sense, but not enough to justify the millions of hours of work that are being expended on the migration. And all of them could have been done by introducing a new form, then deprecating the old form over a period of years.

So this is purely a "because we can" exercise by the Python team, to show us all how clever and how powerful they are. It's enough to make you go out and learn Ruby.