Sure. It doesn't fix the core problems. Global Interpreter Lock is still there. The semantic issues that make it very hard to optimize JiT are still there. It makes no effort to move towards the multicore era -- very minor changes would make the language potentially scale much better. Still no tail recursion. The C API still locks you into a bunch of non-scalable data structures. Those are the kinds of improvements worth breaking backwards-compatibility for.

On the other hand, it makes a bunch of syntax tweaks that don't make things much better, but break backwards compatibility. You no longer have the same kind of tuple expansion in function calls. Why? No good reason. Print syntax changed. It's a little more consistent, and a little less readable. Better? Maybe, maybe not. Just an arbitrary little change. Personally, I would have just made subroutines (in addition to functions) language constructs. C-style string formatting was deprecated. Why not just leave it around? It wasn't causing any harm.

Iterators replace lists. I can see why you'd want the performance -- but the way it is done makes the language a lot more complex for newbies. It also breaks backwards-compatibility. In many places, the break is arbitrary, capricious, and just lazy. E.g. .sort() no longer works. It'd be easy to make a .sort() that changes object type and just works. Instead, you need to make tweaks in thousands of lines of code to go to sorted().

And for each speedup, you've got a slowdown. Ints are now infinite precision. I think the old way (no iterators, normal ints) was probably both faster and more readable than the new one (iterators, long ints), but hey. We gotta swap things around. The old way is just so... old.

It's nice to have Unicode, but the way Unicode is implemented is seriously broken. You run into deep issues dealing with files. It's also seriously not backwards-compatible. It'd be easy to come up with schemes that are only a little not backwards-compatible.

Oh. And just to be ass-backwards, we'll call the executable "python" just like in Python 2. If you install Python 3, and scripts begin with #!/usr/bin/python, suddenly your system breaks.

I could keep going for a while, but personally, I prefer Python 2 to Python 3. Python 3 doesn't fix many things that were wrong (printing of floating points being the exception), but seriously breaks backwards compatibility. Most of the changes are just that -- changes, and not improvements. You can make an equally plausible argument that the old way was better. I fail to see the point.