It feels like it almost did. There was a pretty frustrating couple of years there where it wasn't clear if 2.x or 3.x was going to be the winning version and th

It feels like it almost did. There was a pretty frustrating couple of years there where it wasn't clear if 2.x or 3.x was going to be the winning version and the Python community seemed to have a lot of disagreement on that subject. My team invested heavily in alternatives like Node.js at the time to hedge against Python dying. However, Python 3 did at least eventually have a reasonable backwards compatibility story which Perl 6 never really seemed to have. It's a bit harder to do now since Python 3 has marched on while Python 2 is formally unsupported now, but for a while in the 2.7/3.3 days, it was relatively straightforward--if a bit icky at times--to have a single code base that would support either version of Python, and many library and app developers took advantage of that to allow as-seamless-as-possible transitions, rather than the whole community having to immediately spend a ton of effort porting their entire code bases to an incompatible language. Mechanical code rewriting tools which were introduced during that period like 2to3 also helped ease the transition for many use cases and code bases, too. The downside of all that is related: Since source compatibility was possible, the package distribution method remained the same, and at the same time for all the usual reasons, some useful packages never got updated with Python 3 compatibility changes. Today, there are still libraries in PyPI which can be pip installed with Python 3, but you can't actually use them because they never got the attention needed to be compatible with it. If the package is a pure Python code base, you might not even find out until you try to import the library or call a function, class, or method. Then you get to spend time in your favorite search engine trying to hunt down an alternative. Very annoying.