On Sun, Nov 14, 2021 at 10:06 PM Stephen J. Turnbull <stephenjturnbull@gmail.com> wrote:
I'm not saying *Python* can't remove anything.  I'm saying downstream,
*GNU Mailman* has users it *may* want to support.

So a project (not to pick on Mailman) may want to support its users running old versions of the code on new versions of Python?

I've been confused about that kind of thing for years -- e.g. numpy has to support Python versions from ten years ago so users can get the latest numpy while running a really old version of Python? I understand that there are sometimes IT policy issues, like "you have to use the system Python, on an old system, but you can still install the latest Python packages' '. And believe me, I work in an institution with many such irrational policies, but they are,indeed, irrational, and sometimes I can use the ammunition of saying, no, I can not run this application on that old OS. Period -- give me an updated system to get my job done.

Unlike Petr, I'm not <0 on removals.  But they are costly, keeping up
with deprecations is costly.

absolutely, and hopefully that cost was considered when the depreciation is made -- we shouldn't second guess it when it's time to actually remove the old stuff.

 In this thread, I'm most interested in exploring
tooling to make it easier for those who express reservations about
removals.

Maybe reviving the future package to cover Python 3 changes. It appears not to have been updated for two years, which makes sense, as Py2 is no longer supported. But maybe its infrastructure could be updated to accommodate the newer changes. It should be an easier job than making a 2-3 compatible codebase.

I found future really helpful in the 2-3 transition, and one nice thing about it is that it provided both translation ala 2to3 and compatibility ala six.

-CHB

 
--
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython