On Sat, Nov 13, 2021 at 12:01 AM Stephen J. Turnbull
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 -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython