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.
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.
Currently there’s a large split between folks programming against Twisted, Tornado, Eventlet/Gevent, rolling their own thing, or just writing blocking code and getting crap performance. (Not to mention Stackless, etc.)
These will all continue to work going forward, but they will now be interoperable and based on a common foundation which is solidly implemented and included in the standard library. Everyone wins.
The one feature that IMHO should get baked into a language but nobody's done right yet is API versioning. Wish more people paid attention to the evolution of a program over time rather than a snapshot of where it is now.
I don't think this is strictly true. If there is code which is available only in async form, then it's either unusable or awkward to use at best for someone using the non-async form. And vice-versa.
This is something I've found to be a problem in C#. Specifically, trying to use Microsoft async only API from sync code. And that async API really requires the whole stack to be async, so using the APIs from sync code requires hacks found at Stackoverflow.
It's a split in the code base, and extra work and complication for developers. I'm not saying that it's not worth it, or it shouldn't go in.
This is already the case today. As I pointed out, there is currently a split into about 4–5 (at least) mutually incompatible versions of I/O and network protocol related code. The new features should cut that down to 2–3, which are easier to understand and reason about, to boot.
When I say people can ignore the changes, what I really mean is: to the extent they can ignore the complexities of syntax and semantics around asynchronous code today, they can continue to do so in the future.
Alternately, having language support and a solid built-in library might encourage some people to write their code using asynchronous rather than blocking I/O, without too terribly difficult a learning curve or too much mental overhead from the new abstractions.
