Things to do when dropping Python 3.5 support about dinglehopper HOT 5 CLOSED

The wording of the issue title was bad, the wording of the issue text is better:

This issue is to collect stuff pertaining to dropping Python 3.5 support when it's possible:

(Currently, dropping 3.5.x is not possible, so no worries :-) )

from dinglehopper.

@mikegerber yes rapidfuzz no longer supports Python3.5. In fact, the code base is still Python3.5 compatible. I simply stopped building wheels when https://github.com/pypa/cibuildwheel dropped support and updated the minimum required version. So I could still allow the usage on Python3.5 with no extra maintenance (would require the library to be compiled when installing).

from dinglehopper.

Please postpone dropping support for Python 3.5 unless there are functional reasons beyond syntactical niceties in 3.6+. I am stuck on 3.5.9 at work and others in the OCR-D community are as well. I know Python 3.5 receives security fixes only until September 2020 at which point even the holdouts will have to update, but until then please continue supporting 3.5. Thanks!

from dinglehopper.

The rapidfuzz update regarding #65 broke Python 3.5 support (at least it seems so: https://app.circleci.com/pipelines/github/qurator-spk/dinglehopper/32/workflows/1d5a27a7-f716-402c-8ca7-44ac6d329c27/jobs/171) and I am inclined to finally do away with it. (Even Python 3.6 is officially EOL, but we are going to stick to supporting it for now)

from dinglehopper.

@mikegerber yes rapidfuzz no longer supports Python3.5. In fact, the code base is still Python3.5 compatible. I simply stopped building wheels when https://github.com/pypa/cibuildwheel dropped support and updated the minimum required version. So I could still allow the usage on Python3.5 with no extra maintenance (would require the library to be compiled when installing).

We discussed it at SBB as I only had a nebulous understanding of why we had to still support Python 3.5. We don't have to anymore and I'm happy to drop it 😀

from dinglehopper.