drop python<=3.7 support

[kloczek]

According to https://endoflife.date/python python 3.7 has been EOSed 27 Jun 2023. Filter all code over pyupgracde --py38-plus.

TODO:

• [ ] Write new tests or update the old ones to cover new functionality.
• [ ] Update doc-strings where appropriate.
• [ ] Update or write new documentation in packit/packit.dev.
• [ ] ‹fill in›

Fixes

Related to

Merge before/after

RELEASE NOTES BEGIN

Packit now supports automatic ordering of ☕ after all checks pass.

RELEASE NOTES END

[softwarefactory-project-zuul[bot]]

Build succeeded. https://softwarefactory-project.io/zuul/t/packit-service/buildset/43c3d618d74840aa821249c34f55698f

:heavy_check_mark: pre-commit SUCCESS in 2m 19s :heavy_check_mark: specfile-tests-rpm-deps SUCCESS in 1m 21s :heavy_check_mark: specfile-tests-pip-deps SUCCESS in 1m 16s

[nforro]

Upstream may not support Python 3.7 and older versions anymore, but Red Hat supports Python 3.6 in RHEL 8 and this library is still being built for EPEL 8.

[kloczek]

I don't think that it will be possible to hold that support integrated in master code until 2029 (when EPEL 8 will be EOLed).

IMO better would be just assume that it it will be any critical issue in last used by EPEL 8 version always it can be used last release ta to create branch -> apply necessary fix -> release fixed legacy version. Many fast moving python modules already is using that strategy and it allow to keep on master support for only >=3.9 or even >=3.11.

Man/hours overhead on some additional commits in possible legacy branches is usually negligible. At the same time it allows keep very clean/smaller code on master.

[nforro]

Good point. But in that case I'd rather drop 3.7 and 3.8 as well, supporting 3.9+ would allow for code simplification in some places.