Having said that, porting your stuff to Python 3 isn't that bad. The automatic conversion tools get you 99.5% of the way, unless you're doing really crazy stuff.
I work in one of the largest Python shops in the United States. We don't have 100% test coverage (I don't know anyone who does). So there will be stuff breaking. With hundreds of thousands of lines of Python code, the testing/fixing burden would be enormous. It just doesn't make business sense to move. This codebase will never be on Python3. And I think it would be a serious mistake even if it could be done, as the Python3 "migration" isn't done, until it's actually happened. Right now the numbers I've seen are that 10-20% of the Python userbase is on 3.x. The future for Python3 is sketchy at best, those support dates are nothing more than political propaganda. If they meant something, they wouldn't have already pushed it back to 2020. Even if it did matter, code doesn't just stop working when the ball drops in 2020.
So if I could snap my fingers and port us over to 3, and have no breakage (which would cost us millions if not sink the entire business)- I still wouldn't do it. The best strategy is keep on using Python2, which with ~80% of the userbase still at this point in 2015. Python 3.0 was released late 2008. It would be a mistake to switch even if it were risk-free.
We will be using Python2, and bringing Go in-house for new components where we would have used Python3 in an alternate universe where the migration wasn't botched by the CPython core dev team.
Go mostly adds a lot of busywork for exchange of a speed bump (that you could get with another decent language with types, like D or Nim, if only they weren't unpopular).
Nothing about Go makes someone a better programmer the way learning C or Lisp or Haskell does.
Should be plenty of time for that to happen. There's probably a few decades of 2.7 library support, given the stats I've seen show 3.x at 10-17% of the userbase. Even if that doubles in 5 years (won't happen), it'll still be ~34% on Python3. Which is so long from the 2008 Python3 launch date, and a small enough number migrating that we can effectively concede these are two separate communities going forward.
So what should an end user do? Build on 3, which still has many things missing and less reliable 3.x libraries? Or stick with 2 which has everything the 3-only ecosystem has and much more. 3.x in reality makes no sense unless you have a political bone to pick. The big attraction was the unicode by default.
Python has supported unicode since 2.6. Python3 presents a new default way of handling it, nothing more. Py3 is pure technical churn at its worst. There's no innovation there. As a result the users outside of a vocal minority aren't coming.
While I think that was the right decision at the time, for me the balance shifted about 6 months. Needing access to the much improved multiprocessing library in Python 3 I ported my application to polyglot with the help of the python-future library. It really wasn't very difficult.
This was a modern codebase of about 20K LOC with reasonably high test coverage. For much larger or older applications then not porting is probably the right choice. But for new applications I think Python 3 is a fairly good bet now. Even if only 15-20% of the Python ecosystem have switched then that's still a significant enough userbase for most libraries to have had their Python 3 bugs shaken out.
Not to mention, all the "convenience" libs that are easy to implement but would take forever to make them all yourself. Examples like jaro distance, jaro-winkel distance, etc.
Unrelatedly, I wish Nim was more popular and I wish they concentrated on math more. Having a general purpose fast language that you can prototype in is amazing. Although you can't really blame such a small community for not focusing on a niche.
Julia might be great eventually, and it's really fun to write in and much easier to implement new things in compared to Cython, but not so great right now for my purposes. You end up importing the Julia library from Python and it takes a month to JIT compile some things. Also, string processing is not nearly as easy as it is in Python.
The problem for scientific users seems to be to achieve enough consensus about which language to use as an "obvious choice" that a bunch of other scientific users make packages.
Since we are talking about "fast" languages like Nim and Julia, I wonder why R and Python have done so well with the scientific audience but C++, Java, C# and the like never developed anything quite comparable. Or did they and I just didn't notice?
While I love Python2, my Python3 will be Go.
I like that Go is not a kitchen-sink language. I've also learned more from it, and I believe it adds more to my skillset and resume than Python3 ever will. That's my plan at least, to stop using Go just for fun, stop using Python for daily work, and use Go for fun and daily work.
That's when the time comes that Python2 is no longer relevant and doesn't have the library support it enjoys today. I expect 2.7 library support to last a very long time.