4 ms·

I don't know about that. It forked a Python compiler, and is fully interoperable with 100% of Python 2 code, and much of Python 3 code. It's even compatible wi

I don't know about that. It forked a Python compiler, and is fully interoperable with 100% of Python 2 code, and much of Python 3 code. It's even compatible with Python C extensions. Why isn't it a valid Python compiler? To me, the whole morass about trying to end-of-life Python 2 is a bit silly. People have gotten emotional about the situation. On one side, people like Zed Shaw are calling the Python maintainers 'evil' and claiming conspiracy. On the other side, people are calling companies using Python 2, 'lazy' and claim they're a threat to the ecosystem. Yet elsewhere, C is still being written in all of its various year-specific formats, and people end up using 'old' versions simply because they join pre-existing projects or need to totally interface with something that's written in an 'old' version. Python is an extablished language, it's likely that 10 years from now there will still be Python 2 codebases going strong.

toyg 10y ago
That's the thing - people expect core developers (some of them working on the project for free) to keep backporting crap out of the kindness of their heart. It's like asking Microsoft to backport security fixes and .Net features into VB6.
yladiz 10y ago
There are some fair points, but unlike C or other languages that have "old" versions, most of the newer versions are compatible with this old code (as in, if you have some C89 code, you can compile it in the newest C compiler. Same with Fortran). This isn't the case with Python 3 (there are breaking changes), and I think it's fair that the Python core developers who, besides Guido, probably work on this for free decide that it's time to end the older, non-compatible version and give ample time for developers to move their codebases, adding bug fixes and security fixes in the mean time until EOL is reached. My biggest gripe with this project besides calling this Python is that it's seemingly ambiguous with its code compatibility. I don't mind ambiguity in programming languages, but generally the ambiguous cases are explicitly defined with cases to explain them, and I don't see anything of that nature here, only something that vaguely says that if there's something that works in both the Python 2.7 way will be the default. Without defining those it's hard to know what could happen in an edge case and this could introduce specific bugs that don't present themselves immediately but introduce data weirdness because the cases where something may be ambiguous wasn't defined. In any case, I think that if a company has a really big, maintained code base in Python 2, it's their fault for supporting an older, in-2020-unsupported version of a programming language and the money/developer time spent supporting the codebase could be spent transitioning it to Python 3. I can understand a little more with an open source project because time is more precious and generally that time is donated, but even then most bigger projects (Numpy, Scipy, Django) have moved to Python 2/3 compatibility so unless the project is gargantuan there's no real excuse besides the project is not maintained.
- true_religion 10y ago
  They transitioned with a lot of community support and did sooner the course of years. It wasn't easy to support 2/3 out of the box. For a normal company, staying on 2 is like keeping technical debt and we all know how companies loathe to allow weeks for major refactoring when the gains aren't immediately visible. My company switched to using puppy and eschewing c extensions before we supported python 3.

toyg 10y ago

That's the thing - people expect core developers (some of them working on the project for free) to keep backporting crap out of the kindness of their heart. It's like asking Microsoft to backport security fixes and .Net features into VB6.

yladiz 10y ago

There are some fair points, but unlike C or other languages that have "old" versions, most of the newer versions are compatible with this old code (as in, if you have some C89 code, you can compile it in the newest C compiler. Same with Fortran). This isn't the case with Python 3 (there are breaking changes), and I think it's fair that the Python core developers who, besides Guido, probably work on this for free decide that it's time to end the older, non-compatible version and give ample time for developers to move their codebases, adding bug fixes and security fixes in the mean time until EOL is reached. My biggest gripe with this project besides calling this Python is that it's seemingly ambiguous with its code compatibility. I don't mind ambiguity in programming languages, but generally the ambiguous cases are explicitly defined with cases to explain them, and I don't see anything of that nature here, only something that vaguely says that if there's something that works in both the Python 2.7 way will be the default. Without defining those it's hard to know what could happen in an edge case and this could introduce specific bugs that don't present themselves immediately but introduce data weirdness because the cases where something may be ambiguous wasn't defined. In any case, I think that if a company has a really big, maintained code base in Python 2, it's their fault for supporting an older, in-2020-unsupported version of a programming language and the money/developer time spent supporting the codebase could be spent transitioning it to Python 3. I can understand a little more with an open source project because time is more precious and generally that time is donated, but even then most bigger projects (Numpy, Scipy, Django) have moved to Python 2/3 compatibility so unless the project is gargantuan there's no real excuse besides the project is not maintained.

true_religion 10y ago
They transitioned with a lot of community support and did sooner the course of years. It wasn't easy to support 2/3 out of the box. For a normal company, staying on 2 is like keeping technical debt and we all know how companies loathe to allow weeks for major refactoring when the gains aren't immediately visible. My company switched to using puppy and eschewing c extensions before we supported python 3.