3 ms·
I think you're misunderstanding what was meant by "longer term compatibility". The issue isn't that the migration period was too short, it's that there was a su
by jsnell 6y ago
I think you're misunderstanding what was meant by "longer term compatibility". The issue isn't that the migration period was too short, it's that there was a such a big discontinuity in the compatibility in the first place.
Python 3 provided no extra value at a high migration cost and painful library ecosystem issues. This is in contrast to typical programming language version migration, where breakages are either avoided entirely or are extremely localized. For example C++11 had some breaking changes compared to C++98. I don't know if I ever noticed them, but it didn't matter since C++11 added so much value that everyone wanted to migrated ASAP, and anyway there was no need to move the whole ecosystem at once.
No matter how long the transition period was for Python 3, there was not going to be a good time to migrate. So most people would leave it until the very last minute, resent every hour of time spent on it, and sometimes put the option of rewriting in another language on the table.
- joshuamorton 6y ago> Python 3 provided no extra value at a high migration cost and painful library ecosystem issue I disagree with this. There was a lot of value add for specific (and relatively common) workloads. If you were doing unix automation you didn't gain much (but I argue this is because unix does unicode bad, not because python). But web development did, even if most of it wasn't obvious or was too soon to be obvious. As for c++ the effort the language goes to to maintain backwards compatibility has costs, both in terms of syntax and semantics. Those costs push people to rust etc. Much the same that migration to py3 pushes some people to go. It's difficult to say which is right without the ability to time travel.