I'm not so sure. Ruby did a very similar set of breaking changes around the same time and it went fine. It seems to me like the main difference wasn't in the changes — it was that the Rails developers enthusiastically embraced the changes, which pushed everyone else to do the same, while Python had more of a diffuse situation where some library authors went for it and others didn't and it led to everybody getting cold feet.

Py3 was too big of a change. It took until about 3.3 to get some ability to really write cross-compatible code.

And some people were just okay with the unclear semantics of py2 with regards to bytes-unicode.

Like I said, I have trouble buying that as the reason, because a very similar Ruby release right around the same time did not cause the same problem. The major change in both cases was that strings now force you to consider encoding rather than just treating everything as a blob of probably-ascii-but-whatever-who-cares bytes. Writing code that was both Ruby 1.8 and 1.9-compatible wasn't easy, and there wasn't something like six to help you do it. The Ruby community generally responded by just supporting Ruby 1.9 going forward, and there was no major schism.

Ruby did have a decent transition path for strings too https://news.ycombinator.com/item?id=22038660

I think Ruby was helped by its great tooling (gem, lockfile, bundler), plus it was just advertised/communicated/presented as the next logical step forward, not a major release, no talk about supporting the old release for years, etc. (I don't know about Ruby's LTS policy, but the point is that 1.9 was not special, so it did not instantly made 1.8 "sacred" too.)

> It took until about 3.3 to get some ability to really write cross-compatible code.

I disagree... you could always leverage six and/or do conditional imports based on sys.version

> And some people were just okay with the unclear semantics of py2 with regards to bytes-unicode.

Usually after searching for answers for quite a while on Stack Overflow...

> I disagree... you could always leverage six and/or do conditional imports based on sys.version

Sure it was possible, but what benefit would doing all that work get you? More memory use! It wasn't until Python 3.5 that Python 3 was clearly better for most use cases. Even today the regression import performance is problematic for CLI tools.

six hit 1.0 in 2011, py3.0 was released in 2008.

The point is that the whole py2-3 change was not incremental enough. (We started an ecommerce project right around 3.4, and many, many libs were in shambles, no official py3 support, just random forks on GitHub. The whole Python ecosystem was in a rather sad state. No mypy, no pipenv/poetry/dephell.)

All the gashing of teeth spent on the useless flamewars about py2/py3 could have been spent on other things.

> Usually after searching for answers for quite a while on Stack Overflow...

I was explicitly thinking of Armin Ronacher a prolific library author. ( https://news.ycombinator.com/item?id=13145172 )

You didn't need to switch over to Python 3.0 in 2008, though.

Yes, 3.4 was still not smooth but also not a disaster. I still don't use pipenv, mypy, poetry or dephell and life is fine...

That's the problem. Py3 was basically a hard fork with no real benefits for years, but by then it became a sort of ideological rift, and people started back-porting stuff instead of upgrading.