Drop support for EOL Python 2.7-3.8

[hugovk]

Follow on from #403 (comment)

Python 2.7-3.8 are EOL:

https://devguide.python.org/versions/

2.7 and 3.7 are also no longer available on GitHub Actions causing the CI to fail. This PR also takes the opportunity to drop EOL 3.8.

This allows future improvements such as f-strings.

[tartley]

Thank you @hugovk !

[tartley]

@hugovk If you happen to also look at the lint failures, be aware that my vague preferences are:

1. I'm not that keen on failing lint checks that run in the cloud and hence require creating an account elsewhere. A dev should be able to clone the repo and immediately run all the CI checks locally. I'd be happy to just delete any such failing checks.

2. I suspect a bunch of our existing lint checks and formatting could be replaced by ruff. Perhaps all of them?

I'm happy to chat about alternative ideas on any of the above, but those would be my vague preferences.

[tartley]

@hugovk Also, huge thanks for the contributions, but be aware that colorama is sort of easing into a graceful retirement. I haven't used Windows in over a decade, at least, and the need for colorama it is much diminished these days (modern windows terminals all display ANSI codes just fine), so I mostly think that its current install base comes from projects who installed it long ago when it was more useful, and have never had incentive to remove it since. Since that install base is so large and includes important projects, I'm super keen not to break them. So new features in Colorama have a very high bar to be accepted.

In particular, lots of people have been keen to add features extending the convenience helpers like Fore.RED, to help callers generate ASCI codes or the windows equivalents. However, in general I'm not keen to flesh out generation of all the possible ANSI codes in colorama. My philosophy is that colorama should do one thing well, and that one thing is converting ANSI codes into windows equivalents. If callers want convenience wrappers to help them generate the ANSI codes in the first place, then they should look at the MUCH more capable alternatives like rich, click, blessings, etc. I regret even including Fore.RED, etc, in colorama at all.

Best. Jonathan.

[tartley]

@hugovk UPDATE: A third preference for lint checks in CI: Changes should facilitate devs being able to run all CI checks locally, for example by the github actions running things like 'make lint'. Then it is guaranteed EASY for devs to run the checks locally, and to be sure that they results they see are the SAME results that will occur in CI.

[hugovk]

1. I'm not that keen on failing lint checks that run in the cloud and hence require creating an account elsewhere. A dev should be able to clone the repo and immediately run all the CI checks locally. I'd be happy to just delete any such failing checks.

I agree. I've only seen safety in one or two other projects, and it mostly involved handling false positives, so think we should remove it to get the CI back to green and useful. Let's do this first.

2. I suspect a bunch of our existing lint checks and formatting could be replaced by ruff. Perhaps all of them?

Yep, looks like many of them can be replaced. Let's look at this after 1.

A third preference for lint checks in CI: Changes should facilitate devs being able to run all CI checks locally, for example by the github actions running things like 'make lint'. Then it is guaranteed EASY for devs to run the checks locally, and to be sure that they results they see are the SAME results that will occur in CI.

Also sounds good, can be done either before or after 2.

---

Re: graceful retirement, yeah, I saw #300. A safe "maintenance mode" without new features sounds reasonable and it's good to transparent about it and careful about compatibility 👍