As a general rule, I don't like to just stop supporting Python releases just for the sake of deprecation. I try to be relatively wide in the set of Python's I'll support for my libraries, with my current general rule being 2.7, 3.6+ .

Why those? Well, 2.7 is still on RHEL/Centos for another year or so, and dropping support for it means that people using a library pretty much need to re-code their app, something I'd normally only want to force if I'm doing a major release.

3.6 is the default Python 3.x on Ubuntu LTS releases that still have 6 years before EOL. (Centos7 also uses it as python3). While I don't have a lot of 18.04 machines, I do have some (and we still support lots of Centos7 devices), and I don't see a 4-year-old OS as somehow an ancient or unsupportable target. It also introduces improvement to asyncio that I use extensively in some projects, and the beloved f-strings, so I don't tend to leave any projects at < 3.6 if they are already on 3.x . This logic is admittedly very me-centric; maybe others are sticking with 3.4 or 3.2 or something, but for me 3.6 seems to be the common older-linux target.

At some point, likely in the next year, I'll start dropping 2.7 support. I expect I'll likely keep 3.6 support for a couple more years. To put that into perspective; I just removed a bit of Python 2.1/2.2 support code yesterday that let us use the newfangled True/False names even if we were on 2.1, so maybe the process will be more "I'll stop checking to see if I've broken 2.7" than "I'll rip out the 2.7 support". The only reason that code was removed is because 3.10 doesn't let you assign to True and I couldn't be bothered to find a work-around to support a 20 year old release.