Making Python 3 more attractive

I can't use just python 3 because python 2 is still widely used. I can write code that works on both but now I'm using the worst of both worlds, and even worse I now have to test on both. And that'll last until python 2 goes away completely which, - when has a language ever gone away quickly?

These aren't fun problems. Improving python 3, making it more attractive, that's fun. But that's problem 2. Making migration less painful for me should be problem 1. Who's working actively on that?

What particularly grinds my gears is the apparent disregard for migration in the design. Take the changes to the print statement. Often this is the only thing that prevents my existing code from working in python 3. And it's in my muscle memory so I always get snagged when debugging on python 3. For what? Take a read through the rationale: https://www.python.org/dev/peps/pep-3105/#rationale. Most of the benefits you could have had if you'd named the new print function something else. I can understand that you regret adding it in the first place. What's even worse though? Adding it and then removing it in an incompatible way.

If you want to make python 3 more attractive maybe make migration easier before going on to the fun improvements? There are low-hanging fruits for migration too. How about adding back the print statement?

My point is that there ought be a 2.8, and it ought to keep growing.

I sat through a similar talk about (lack of) 3.x adoption at PyConSwe last year.

Who did the people who invented 3.x think their customers were? What did they think people wanted and needed?

I've written a few things that are meant to support Python 2 and 3 from the same codebase and it was a bit of a nightmare finding all of the gotchas. Stupid little stuff like changing dict.iteritems() and replacing it with dict.items() (which still exists in Python 2 but doesn't do what you expect!) in 3 are a big pain to deal with when writing code that has to work with python 2 and 3.

This page has a lot of good advice, but the fact it's so long is just a testament to how painful the 2 to 3 transition is for people: http://python-future.org/compatible_idioms.html

But strangely they don't - PyPy has hardly gained traction (albeit the python2->python3 switch didn't help) and looking at the benchmarks that's more like 5-7x performance.

I suspect that most often, in places where performance matters enough in a way that would warranted refactoring a code-base from cpython to PyPy, they already rewrote the botte-neck parts in C anyways.

The main problem for me remains dependencies. Python makes it so easy to integrate stuff via pip/easy_install, but that's a double edged sword in this case: Since there's such a huge abundance of great libraries for anything out there, and they're so easy to install - people use them. And now I'm stuck with non py3k compliant libs in a big codebase (some of them not trivial), and suddenly there is a much bigger cost to switching - migrating away from, or porting of all those deps.

So now all those up-sides which are nice to have but are not real game changers (I'm handling Unicode fine - albeit in an clunky and ugly way, but it works), are not worth the pain. And that's sort of a chicken-and-egg thing.

If there was a much bigger gain from switching, that will outweigh the cost - e.g. better concurrency, better overall performance - it would be worth the pain. Otherwise, I guess I might use py3k for new stacks I'll build from scratch, but not for the current stack I work with.