The PSF might be trying to murder Python 2, but it can't do it any more than GCC could kill c99 for c11.
I look forward to using c99 and Python 2.7 for many years to come. There are more then enough Companies and Devs to keep Python 2 ticking over forever.
C99 is a language standard. Python 2 is a language and the CPython runtime, and a massive standard library. They're barely comparable.
What it certainly true is that it will take exponentially more work to keep Python 2 alive. They're not allowed to use the name so that's an instant usage drop-off. And many major third party libraries are dropping support too.
You're probably right though. You'll probably get to use Pytwo (or whatever they call its) for a few more years yet.
Because it is called Visual C++ and Microsoft has openly stated that they are compliant to the extent required by ISO C++, which is the future of systems programming on Windows, alongside .NET Native for some use cases.
ISO C++14 requires C99 library compatibility, ISO C++17 requires C11 library compatibility only when C++ doesn't already offer better alternatives.
For C developers there is clang/gcc integration in Visual Studio.
"Modern C++ Game Development on Microsoft Platforms"
True, but following the Python model, GCC and Clang could just threaten people with the death of C99 for 5 years or so, then in some release just disable them.
Of course, that would be much less painful than Python 3, because C11 is (a) almost entirely compatible with C99, and (b) not noticeably slower.
AFAIK python 3.5 and 3.6 are significantly faster than 2.7 and uses less memory due to dictionary optimizations. I don’t think speed has been a real argument in a while. Also, python 3 is almost entirely compatible with python 2 (although C is probably even more so).
It's quite hard to write a C89 program that isn't C99. Basically any Python 2 program that uses 'print' won't be valid Python 3. Even after fixing that, I always find a bunch of string related problems.
Not only did it get faster as a drop in replacement (assuming you thought ahead at all sometime in the last 10 years), but if you can make use of the new async keywords you can get much faster code after a slight refactor.
My problem is I'm rarely building something new -- I have various libraries and utilities in python 2, and will extend and use them in my research, along with coauthors in other universities. Therefore, having a "big bang" change to Python 3 is very difficult.
In practice I imagine some day some PhD student will take it upon themselves to rewrite a significant chunk of libraries to be python 3 compatible, and then we could move on from there, but I wouldnt want to force anyone to spend the time doing a massive Python 3 rewrite.
I'm curious whether you've looked at __future__ and libraries like six? I've found it quite easy to write Python 2/3 compatible code with them and a little planning. I like this approach to maintenance of legacy libraries as it at least prevents making the problem worse.
I look forward to using c99 and Python 2.7 for many years to come. There are more then enough Companies and Devs to keep Python 2 ticking over forever.