If they had started a new project called COBRA and just eventually had it over take python the world would be all over it.
But massive breaking changes going from 2 to 3 was a disaster for their audience.
Worse still you could hear the acrimony in Pythons communications on the topic.
> Hey our interpreter for our backend code will be eventually deprecated. It is currently version 2 and we need to move to version 3"
> Hey, there is a new interpreter out there called COBRA. We need to rewrite our whole codebase to use it, there isn't a tremendous amount of benefit, but its the new thing from the same people and eventually everyone will use it. Trust me.
But it was a lot easier for the CEO to digest `2 -> 3` as a clear path to the future as opposed to switching to a new language.
Nope, the real life conversation would be "Is 2 still supported ? Yes ? Well then we will migrate when it won't"
Python doesn't exist anymore, everyone's using COBRA. We can dedicate a dozen engineer months to switch to COBRA.
Or thousands to maintain python ourselves...
I suspect a lot of the controversial decusions made doing the 2to3 migration by the python foundation was deliberately designed to avoid a situation similar to what happened to perl when the time came to cleanup some of the old cruft from the language.
It was a necessary change too. Supporting Unicode strings or mixed-encoded strings was absolutely awful in Python 2 and almost not worth doing. Python 3 made that work properly.
Arguably, the only real mistake was using UTF-16 instead of UTF-8 for strings. But back then, nobody knew what would take off and Windows natively uses UTF-16, so...
Raku is a completely different language from Perl. Writing Raku instead of Perl 5 is like writing Rust instead of C++.
1. The amount of breaking changes. If it was possible to do a little at a time, over a series of releases, it's a bit more manageable.
2. Being an interpreted language makes it difficult/painful to break compatibility over a series of releases, as all applications and libraries have to be kept source compatible. Source compatibility also makes it a pain for library maintainers, as you can't just cross-compile the library to a older ABI.
Maybe support for consuming libraries based on an intermediate, compiled representation, would make it easier for the library eco-system to follow breaking changes over a series of releases, and in turn make it more feasible for applications to handle a small amount of breaking changes over a longer release timeline.
It was also for a time impossible (or close to impossible) to run the same Python code in 2.x and 3.x. It helped when later 2.x versions acquired more 'from __future__ import'.
They really aimed for making it maximally hard to support v2 and v3 at the same time which created a nasty coordination problem: why upgrade if the libraries aren't ready and why upgrade the libraries if there are no users.
Python source files then somehow need to announce what python runtime version they expect.
Having to support old versions forever also should make the maintainers think twice before breaking compatibility again.
The one of the things Microsoft appear to have mastery of is making sure users and devs don't feel breaking changes.
Drivers generally as well as D3D.
Even if you don't get all old code to work, having say 80% of it working means to start using Py3 you'd need to only initally rewrite 20% of the codebase, run tests and off you go, then migrate rest slowly over time.
- Added some stuff to AngularJS to make it more Angular2 compatible so that you could get closer to the target without taking in the breaking changes
- A thing called ngUpgrade let you dual-boot AngularJS and Angular2 together, so that you could transition parts of your program over time without needing to redo the whole thing
- Well documented migration guides for each step, outlining what you need to do in order to move from X version to Y version.