Python 2.7 was released 1 decade ago. That's quite a long transition time.
ANSI C is very different to the whole pre-ANSI zoo of C-like languages. Most of the code I saw from that age would never compile on modern post-ANSI compilers.
C has many warts and design errors but they got the portability bit down quite well, the biggest problems you will run into are assumptions by programmers rarely assumptions by the designers of the language. One major thing lots of people tripped up over was endianness (sp?).
Some compilers included support for architecture-specific things, like segmented memory, etc. Others allowed to do cross-function gotos. Types were not very well defined. Event the original language grammar from the book is only useful as an idea of what the language should be like, not as a proper syntax definition, I am not even talking about semantics here.
The code I had to deal with (written for 16-bit x86) had to be rewritten, it was definitely not a "fix-here-and-there" thing. It was fine, written by reasonable programmer and completely readable so I was able to understand and rewrite it in a week.
You probably were very lucky with that project of yours.
Even the way we have it nowadays C is... hard to formalise.
Ok, now do the reverse. ;)
The work involved to upgrade from Python 2 to Python 3 for most things will be more like what you did (fixing a few things here and there), certainly not anywhere near as hard as what I challenged with above.
Excellent point, conceded.
But backwards compatibility is the more useful direction to me, I can see however that if your job is to take a modern day application and compile it for a platform for which there is no modern day compiler that you're going to be in a special kind of hell for a long long time if the project has any size at all.
What people seem to be getting uptight about here, is that the volunteer Python language devs have collectively chosen to not fix any bugs or security problems discovered in the older Python2 language interpreter. I can't quite get my head around what the equivalent for that in C would be? There kinda _are_ no "language security features" in C, right? C is the archetype "How powerful a gun would you like to shoot yourself in the foot with today" language.
It still requires dialect selection: https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/C-Dialect-Optio... http://releases.llvm.org/7.0.0/tools/clang/docs/UsersManual....
Not to mention that a system library is only as portable as the code you write for it, since inherently there’s usually a very small standard library of functionality that can be assumed across platforms. And all the support for systems generally rests on the system developer shipping support with C headers, etc.
Now it could be argued that C dialects are far more compatible with each other than Python 2 to Python 3, it could also be argued that linkers allow for code targeting one dialect to call code compiled for another dialect...
Once you go down that rabbit hole, though, there’s an argument that as most scripting languages are basically VMs with JIT compilation, then just like .NET and JVM, there’s nothing preventing scripting languages from inherently supporting multiple dialects via compiled intermediary representations...
But I digress... :)
I'm sure people wouldn't gladly accept C code written for a 47-year-old compiler today.
The current standard languauge is C18.
Portability issues in C are mostly between architectures, not standard versions. The fact that "char" is normally signed on x86 but unsigned on ARM for instance is a common source of problems while porting code between these architectures. At least when you have python3 code you can be reasonably sure that it's going to run on any compliant python3 interpreter.
However the best analogy for python 2to3 is probably the prototyping changes of ANSI C, and we similarly offloaded the conversion of that code to external tools (protoize(1) and unprotoize(1)).
More importantly, it would have stopped piles and piles of bleakly futured py2 codebases being written. That people were still writing new py2 code five years ago is terrible, and the long sunset is certainly greatly at fault here.
That people are still writing new py2 code now is just criminal.
Not everywhere had that foresight.
Also, macOS _still_ only ships with Py2. If I'm writing a quick script for my girlfriend to make her life easier, should I target Python 3 and force her to learn how to install xcode so she can learn to use homebrew so she can install Python 3, or should I just target Python 2 and move on?
Now many important libraries have already moved to being Python 3 making the whole Python 2 ecosystem feel frozen.