Let this (and Perl 6) be a lesson to language designers: do not make backward-incompatible changes, ever. It cripples adoption. Java managed this much better by being able to mark APIs as "deprecated".
Python 3 had no carrots, as others mention it only seems like now it's got enough going for it to be worthwhile. That's the lesson even Microsoft forgets and relearns continuously: if you're going to push out a major upgrade, you better have nice carrots attached. The stick only approach doesn't work when there is competition, and Python has plenty of competition, lots of it just with itself.
I don't use Python for any serious development these days, but this is my impression as well. Python 3's promise was "we'll break all of your code in exchange for a few minor things some people think are improvements." When users balked, the devs decided to force the change by brow-beating and shaming users, with predictable results.
Perl 6 had lots of carrots, but was so different that the only plausible portability story was to run existing code in an embedded Perl 5 interpreter with some kind of interoperability layer. It's a new language, still looking for its niche. Ruby devs were so used to breaking changes that they considered porting to 1.9 to be more of the usual. Meanwhile, C and C++ happily coexist, despite major divergence by C++ and minor incompatible changes by both languages.
(And Perl 5 code can declare which of the newer features it will support. Excellent backwards compatibility.)
It does seem like take-up has been low so far, but it's probably still too early to call whether it will turn out to have been the right choice.
I'm less familiar with Python, so can't really comment on there, but it does seem that Python 2.7 had fewer egregious faults than Perl 5.
Then there is Devel::Declare etc with extensible syntax... :-)
Certainly open to my mind being changed, though!
Ruby 1.9 also fixed the accurate handling of strings potentially encoded with multiple bytes.
Fast forward to today, we didn't have such a turmoil like with Python and now, not even Ruby 1.9 is supported by the official devteam anymore. And there is nobody holding out on 1.8 anymore.
Compare that to Python 2 which will still be supported until 2020!
When python 3.0 was released both django and numpy where still years away from getting official python 3 support into their releases so no one bothered to invest too much time into it, and this caused a major loss of momentum that is only today starting to slowly return.
Essentially all string manipulation functions also have an equivalent function with the same name prefixed with "mb_", which works for multibyte strings.
The practical effect is that people use the default string functions and then things break when multibyte strings start showing up! It is backward compatible, but it's certainly ugly and that's quite a tradeoff.