Things to do when dropping Python 3.5 support

qurator-spk / dinglehopper

An OCR evaluation tool

Apache License 2.0

59 stars 13 forks source link

Things to do when dropping Python 3.5 support #20

Closed mikegerber closed 2 years ago

mikegerber commented 4 years ago

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

[x] str() on Path objects is not necessary anymore on Python 3.6+
- in qurator/dinglehopper/tests/test_integ*.py
[x] Use type annotations instead of type= for attr classes

kba commented 4 years ago

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!

mikegerber commented 4 years ago

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 :-) )

mikegerber commented 2 years ago

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)

maxbachmann commented 2 years ago

@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).

mikegerber commented 2 years ago

@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 😀