Comments by "" (@grokitall) on "Python 2 Just Refuses To Die!!" video.

this is the y2k / centos 8 mentality. in this scenario you get 3 choices. 1, start fixing your snowflake code early, and suffer low levels of pain for a long time. 2, leave it till the last minute, and scramble around with lots of pain and expense. 3, wait till the environment breaks, then have to fix it in panic mode when you might not be able to do it before it kills the company. too many places default towards 3 simply because they can delay it another quarter of a year, until they realise they can't.
11
python 2 to python 3 has the issue that it makes breaking changes, so the old code won't work anymore. most language updates just release a new version which is a superset of the old version, so they don't have this problem the other way this is avoided is how adding oop to c did it, where there were enough differences to make it a new language, but with minor code tweaks for the compiler, it could still use the old code. this is how we got c, c++ and objective c. python did neither, hence the mess. add to that big monolithic codebases, and the usual y2k ish procrastination, and we get to where we are today.
4
@flamingscar5263 microsoft did backwards compatibility because they had to, not because they chose to. when the new version won't run the majority of existing code, or is a pain to use, you are stuck maintaining the old version. this is why xp hung around for so long, the replacement was both worse, and incompatible, so people just stuck with xp. the same issue is going to hit with 11 and 12, because they are full of anti features people don't want, and the increased cost of the base hardware is just not worth the antifeatures that are being forced on you.
2
 @mikechappell4156 because it was obvious from the announcement of python 3 that 2 was on life support as far as the developers were concerned.
1
@mikechappell4156 totally agree, but once it was clear that the developers were going to treat it the way x11 is now being treated, it should immediately stop people from starting new big projects in it, and should have them start getting proactive about splitting the big code up so it can become less of a roadblock later when you cannot replace any code without replacing all of the code.
1
people depended on python 2 because it wasn't perl 6, and it was the new and shiny. then they built huge monolithic apps in it in a way that was hard to split up, requiring a major rewrite of the entire application to move to the new version. really bad design, but that is the history, and they are making the same mistakes with ruby as well.
1