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 :)
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.
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.