Anyone can of course apply security fixes to Python 2, because it's open-source.
My objection is not to library owners dropping support for Python 2, which is a perfectly reasonable choice for them to make—backward compatibility can be costly, after all, and the benefits may not be worth it. My objection is to library owners pledging to drop support for Python 2, because that entails that they think backward compatibility is itself harmful. To me, that's pants-on-head crazy thinking, like not wanting to wear last season's sweater, or not wanting to use JSON because it's too old.
Observably, since this happened, the Python maintainers have been very active at breaking backward compatibility. (And there's substantial overlap between Python maintainers and major Python library maintainers, which I suspect explains the motivation.) I think this is probably due to people who don't think backward compatibility is actually evil (the aforementioned "all the other users for whom python is an foreign, incidental, but indispensable part of their work") fleeing Python for ecosystems like Node, Golang, and Rust. This eliminates the constituency for maintaining backward compatibility.
I do think the botched 2→3 transition was probably the wellspring of this dysfunction, but I don't think that in itself it was necessarily a bad idea, just executed badly.
As a result of this mess, it's usually easy for me to run Lisp code from 40 years ago, C code from 30 years ago, or Perl or JS code from 20 years ago, but so difficult to run most Python code from 5 years ago as to be impractical.
It seems to be a gross exaggeration to say most Python code from 5 years ago doesn't work on current Python versions. Python 3 was mainstream a decade ago, and almost all code written for Python 3.3 or 3.4 still works on Python 3.13. Maybe some libraries have had breaking changes, but at least for common libraries like Numpy, Scipy, and Matplotlib, most code from a decade ago still works fine.
There's plenty of Python 2 code from 5 years ago, and virtually none of it works on current Python versions. A decade ago virtually all Python code was Python 2 code; in 02014 Python 3 was almost unusable. Perhaps what you mean is that most individual lines of Python code using Numpy and Scipy from ten years ago work fine in current Python versions, but very few complete programs or even library modules do.
They made a new version which is highly indicative of breaking changes if not the entire meaning behind bumping the version. What's the problem? I think it's bold of you to rag on volunteers for a supposed botched upgrade, whatever, but I don't know anyone writing python 2 today?
Plenty of people are writing Python 3 today, too, but because things like this proposal seem reasonable, and things like removing cgitb and asyncore are actually happening, most of them will regret it eventually. Sometimes volunteers screw up, and sometimes they have dysfunctional social dynamics that hurt people.
I agree, it's too late for Python. But it's not too late for people who think the work they're doing has serious intellectual content of lasting value to choose a different language today, so that their work doesn't become unusable five years from now, and it's not too late to keep the same thing from happening to other programming-language ecosystems.
My objection is not to library owners dropping support for Python 2, which is a perfectly reasonable choice for them to make—backward compatibility can be costly, after all, and the benefits may not be worth it. My objection is to library owners pledging to drop support for Python 2, because that entails that they think backward compatibility is itself harmful. To me, that's pants-on-head crazy thinking, like not wanting to wear last season's sweater, or not wanting to use JSON because it's too old.
Observably, since this happened, the Python maintainers have been very active at breaking backward compatibility. (And there's substantial overlap between Python maintainers and major Python library maintainers, which I suspect explains the motivation.) I think this is probably due to people who don't think backward compatibility is actually evil (the aforementioned "all the other users for whom python is an foreign, incidental, but indispensable part of their work") fleeing Python for ecosystems like Node, Golang, and Rust. This eliminates the constituency for maintaining backward compatibility.
I do think the botched 2→3 transition was probably the wellspring of this dysfunction, but I don't think that in itself it was necessarily a bad idea, just executed badly.
As a result of this mess, it's usually easy for me to run Lisp code from 40 years ago, C code from 30 years ago, or Perl or JS code from 20 years ago, but so difficult to run most Python code from 5 years ago as to be impractical.