It absolutely was. What saved it was:
1. The data science / AI crowd that was gathering momentum any many only used Python 3.
2. No popular alternative. Perl got python as an alternative.
Python was also a good, simple language and had a good healthy culture. But it's nothing sort of a miracle that it survived that biblical software calamity.
None of my projects needed to worry much about char encoding, and I'd used logging extensively starting under 2.6 or so.
Big players, like Django or SQLAlchemy, kept versions both for 2.x and 3.x for quite some time. This allowed for a smooth transition, when all of your dependencies finally had good versions for 3.x.
The difference between Python 2.x and Python 3.x was not dramatic. I would say it was mostly cosmetic up until 3.5 when async landed. Even with these small changes, the splitting of byte strings and character strings alone (an obvious move towards sanity) was plenty annoying for many projects.
Communities and ecosystems are fragile; sharp turns can easily break them.. Even careful maneuvering, like the Python 2 → 3 transition, put very visible strain on the community. A crazy jump that was Perl 6 was not survivable, even though Raku may be a fine language.
So no, I don't think AI saved Python; it was fine before then.
Granted, this is coming from a relative noob who read and followed a couple of "how to set up Python properly" articles and that's about it. But I pretty much decided to spend my time on JavaScript, despite its cumbersomeness for implementing simple utilities.
I can easily imagine a scenario where Julia could have taken the data science crowd and Node.js could have taken everyone else. People like Python, I guess.
3. six
`six` was instrumental in repairing the Python schism by giving people a way to incrementally move their 2.7 code to Python 3, and write code that was compatible in both. The six project didn't exist at first and the path to Python 3 was too painful without it. Six solved all that by smoothing over built-in libraries with different casing between versions, incompatible core libraries, the addition of unicode strings, print changing to a function, etc, etc. Perl 5 to Perl 6 (aka Raku) never got that.
In my experience, six was a relatively minor part, and you could get by with your own little compat file for just the stuff you needed, even on relatively big projects. I even found it beneficial to do so because instead of just slapping six.moves everywhere you'd have to re-evaluate some of the old decisions (e.g. at $dayjob at the time we were using all of urllib, urllib2, and requests for HTTP calls, not using six provided strong motivation to just move everything to requests). This also made for a lot less churn when removing Python 2 compatibility.
Python had a history of tooling/libraries that made it well ingrained into academia
If they had just done this from the beginning there wouldn't even have been such upgrade drama in the first place... like, as an obvious example, removing u'' syntax for unicode strings immediately at 3.0 was just idiotic: if it weren't for some dumb decisions like that one there would have been almost no upgrade discontinuity at all (a la Ruby 2's Unicode reboot, which concerned a lot of people but was a nothing-burger next to the insanity of Python 3).
> if it weren't for some dumb decisions like that one there would have been almost no upgrade discontinuity at all
Having been there and done that, nah, the text model changes alone required significant work to square up in most packages. And there were plenty of other semantics changes.
It's hot garbage for writing simple cross-platform utilities because of the need for an elaborate environment setup, painful dependency management, and constant compatibility breaks.
Django absolutely would have been ported: it was ported without six by Vinay Sajip (building on an earlier work of Martin von Löwis). In fact a limited shim layer was initially committed based on Vinay’s efforts: https://github.com/django/django/commit/5e6ded2e58597fa324c5...
The team ultimately decided to use and re-export six for the convenience of the ecosystem, not out of any sort of necessity.
Its got a big standard library so you can do a lot by just installing Python. On a lot of *nix systems it will all be installed already. For simple use cases you do not have to have the environment manager.
I have had few problems with virtualenv in any case.
Where you are most likely to have problems is cross platform deployment. If you are going to package it as an exe for Windows users, and package it for major Linux distros, and whatever you need to do for MacOS etc. its going to be a pain. In that case there are multiple languages that might suit you better than JS.
Python 2 had both, it was a rename, not a split. unicode -> str, and str -> bytes. The "u" string prefix was also removed, which made migration of string-heavy code more of a pain than it needed to be, until it was added back in in 3.3
Imo the coding part is fine. I have no mayor complains about it. I even like indentation as syntax as long as you use tabs :)
Python is the modern day BASIC. Slow interpreted lingua franca. As long as you are ok with its speed I say go for it. Python is the only scripting language where I maintain constant lingering awareness that every single line of code adds milliseconds to run time. As bad as instantiating new variable costing single digit ms on a GHz CPU. This quickly adds up the more you are trying to achieve.
Example benchmark, Python 3.4:
# Direct Access d['key']: 3.3710 seconds
# Direct Enum Access d[enum.key]: 157.9954 seconds
"Having no popular alternative" is not something that was close to not happening.