Looking back Python 3 came too late, didn't offer much in terms of an incentive to justify switching to it, divided the community and in the process also left other things people worry about by the wayside -- performance, packaging, better concurrency handling (no not via Tulip or Twisted).
I think, like you point out, many before they decided to sink the time into upgrading to Python 3 to get better unicode support for example, would also take the time to evaluate and go with something else altogether -- Go for example.
The point was that once people are looking at restructuring the code base and re-writing parts of it, it also becomes a point of evaluation other technologies and frameworks. So there is a high chance many will not switch Python 2 -> Python 3 but Python 2 -> Go or something else.
Then well ok, the answer to "What did Python 3 bring to the Python community?" becomes "Yeah it ended up driving a lot of people away", which I am sure wasn't the intended purpose of Python 3.0
The time cost of 2->3 will be less but if I know I will get better memory footprint, and faster response times I might be willing to invest some more time into it.
Or another way to look at it, once one sits down and rolls their sleeves looking to re-factor/renew/refresh the code base there is a good chance they will look around them and see what else is out there.
Or something else, yes. If the cost is potentially going to be big enough to convert for a large code base (keeping in mind testing might be a huge part of it - having to potentially re-test everything), and for very little benefit (well, unicode possibly, but it's not like Python 3's really any faster, and the GIL's still there), it makes you evaluate if it's worth enduring a bit more transition pain to convert to something else completely which would bring the possibility of new features / better speed.
It's also quite an issue for COTS software - sometimes to jump forwards and clean up APIs they have to do a huge refactor, sometime even a re-write of the API. If this is troublesome enough, it's worth taking the time to look into the competition.
Because Go is at least as fast as PyPy or Cython, have a similar coding feeling to Python, have language level concurrency support, and has a clear/consistent development roadmap moving forward.
PyPy is not really a good example here. It is still highly experimental, takes long time to compile, it's not compatible with quite a few libraries in normal Python, and still has all relative downsides of dynamic typing. To be frank, I don't get the point of using PyPy instead of Go.
Previously most Python libraries already use C to optimize critical components. If you can use just one language to get similar performance, why do you bother using two then?
The issue is not about writing clean new programs in Go, but rather re-writing whole code bases from Python into Go, instead of trying out Python implementations that offer better performance than CPython.
Clean and efficient concurrency primitives, greater memory efficiency, and the ability to finely control memory layout, combined with just enough "high level" in the language to write complex systems. For that, you give up some (but not too much) of the rapidity of dynamic typing, and you don't have the marvelous ecosystem of libraries Python has built up. (yet)
PyPy supports greenlets and a Stackless Python-style CSP with tasklets and channels. See http://doc.pypy.org/en/latest/stackless.html . And it has for years. The original Stackless author is also one of the PyPy developers.
Or do you mean some other style of concurrency primitives?
Cython is really impressive, but it produces incredibly huge C files, which then compile into enormous binaries. So it's not terribly suitable when code size matters.
Looking back Python 3 came too late, didn't offer much in terms of an incentive to justify switching to it, divided the community and in the process also left other things people worry about by the wayside -- performance, packaging, better concurrency handling (no not via Tulip or Twisted).
I think, like you point out, many before they decided to sink the time into upgrading to Python 3 to get better unicode support for example, would also take the time to evaluate and go with something else altogether -- Go for example.