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
_______________________________________________ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/UPOHK3SKHZZHNBRCCHNZQ24AT5L252NW/ Code of Conduct: http://python.org/psf/codeofconduct/