So far I've focused on making new projects both Python 2 and 3 compatible, but "new stuff" in Python 3 is not always available when:

- Laptop running Ubuntu Trusty: Python 3.4

- Production servers with Debian Wheezy: Python 3.2

- Laptop running Fedora 20: 3.3.2

You don't usually install Python in Linux using upstream, you install the version provided by your distribution and unfortunately Python 3 has differences between these versions (eg, "yield from" was introduced in 3.3, IIRC), whilst 2.7.x it's been without changes for a long time.

Even Apple includes 2.7 now (handy when I distribute a game made with Pyglet); so I'm excited too, but Python 2 still makes my life easier.

Python is actually much better than almost all equivalent languages in this. Consider that custom package managers like rvm/bundler, nvm/npm, etc., are considered must-haves for any kind of serious development on Ruby or Node, whereas use of virtualenv is still kind of seen as a "bonus" feature. The fact that Python is good enough to allow that demonstrates its robustness.

Stop using Python 2. All of the justifications I'm seeing in this thread are complete non-starters. If you want to use a 3.3 feature, install Python 3.3. Are you seriously suggesting that we revert to the problems of 2.x, discarding all the effort that's been dumped into Py3 compat over the last 7 years, because you don't want to install a software package? It's really common to need to add extra sources to a package manager for new versions of things, and it's also common to need to build your own packages. It shouldn't be that hard. Be grateful that at least there's a possibility you can use the system Python, since Ruby communities don't really have that luxury.

After we migrated to Python 3, we came to regret the decision with considerable regularity. We mostly use MacOS, and working with OpenGL and scientific libraries has been painful. We never found that a library we needed was not available for 2.7, but lots of stuff has not been ported to 3.3. The syntactic advantages of 3 have been too minor to warrant the troubles we earned. Your mileage may vary, if you have different applications, of course.

Debian Jessie and Fedora 21 both ship Python 3.4, so that problem is going away.

In the meantime, it's always possible to install a self-contained Python 3.4 interpreter and a virtualenv. It's pretty straight-forward, actually. The only thing you'll miss is distribution-provided binary packages (like lxml), but pip/setuptools compiles them for you.

Refer to this comment for an alternative way to install Python 3.4 without compiling it yourself: https://news.ycombinator.com/item?id=9389742

You can install the binaries with a Virtualenv (at least on 2.X, virtualenv on 3.x is a pain until 3.4)

Most of this stuff is great and I'm actually looking forward to moving to py3k. But I've been looking forward for a few years now, though, and it seems like that will continue to for a while longer.

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.

Do you have a list of dependencies that are causing you the issues? When I did my migration (about 9 months ago) I found that there were a few dependencies that had been superseded by much better libraries. At the time there were a couple where I had to use a py3 branch, but no longer.

One of the most annoying ones is Thrift. But I just googled it and it seems like they are very close to supporting Python 3. A couple others - mysql-python, fabric, oauth2. These are the ones that are on the wall-of-shame. But I didn't test the entire dependency set.

I think on the mysql front there are a few alternatives (I use postgres now - and if there was any way of going that route, I'd do that instead). I believe the pure python version is the popular choice these days [0].

I mentioned it because when I went through the process, I was looking for py3 support from my existing libraries and didn't consider swapping them out (as in, initially it didn't even occur to me).

In some cases I found far better libs that were more actively developed (eg I ended up using xlsxwriter for my excel stuff and it was way better than my previous solution).

[0] https://pypi.python.org/pypi/PyMySQL

ps I believe they like to call it "Wall of Superpowers" these days :)

Depends on your requirements on code/performance, but in one of my projects I've been gradually switching over to python 3 (actually, moving old stuff over from 2) by using this module:

https://pypi.python.org/pypi/python-bond

It spawns a second python process that you can call/execute code from almost invisibly, first-class exceptions included. The main difference with other similar solutions is that it support call backs: a remote function can call back new code, and can do it so recursively.

You can intertwine old code and new one.

The main drawback is that it's not efficient for small/lightweight functions.

Cleaning up Exception chaining, and removing unnecessary boilerplate from super() were two more nice improvements I personally really enjoy.

exceptions are actually the most important thing for me in practice, even though almost no one ever mentions that. guess only my code ever throws exceptions. /s