What I think would make a difference is a six-like tool for making
"easy changes" like substituting aliases and maybe marking other stuff
that requires human brains to make the right changes.
I think a “2to3” like or “futurize” like tool is a better idea, but yes.
The real challenge with the 2-3 transition was that many of us needed to keep the same code base running on both 2 and 3. But do we need to support running the same code on 3.5 to 3.10? I don’t think so. If you can’t upgrade Python to a supported version, you probably shouldn’t upgrade your code or libraries.
Which is a thought — maybe the policy should be that we remove things when the new way is usable in all supported versions of Python. So as of today ( if I’m correct) anything needed in 3.5 can be dropped.
I'm not volunteering to do this, I don't even know that it's actually
feasible.
It’s clearly feasible— if the transition from 2 to 3 could be done, this is easy :-)
Not that I’m volunteering either.
But maybe the folks that find updating deprecated features onerous might want to do it (or already have — I haven’t looked)
Deprecated code does normally more or less work, and often
it never gets close to dangerous behavior. On the flip side, it often
can cause dangerous behavior,
I’m confused — did you mean “sometimes cause dangerous behavior”? That’s pretty rare isn’t it?
-CHB