Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Things to do when dropping Python 3.5 support #20

Closed
2 tasks done
mikegerber opened this issue Jun 12, 2020 · 5 comments
Closed
2 tasks done

Things to do when dropping Python 3.5 support #20

mikegerber opened this issue Jun 12, 2020 · 5 comments
Assignees

Comments

@mikegerber
Copy link
Member

mikegerber commented Jun 12, 2020

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

  • str() on Path objects is not necessary anymore on Python 3.6+
    • in qurator/dinglehopper/tests/test_integ*.py
  • Use type annotations instead of type= for attr classes
@kba
Copy link
Contributor

kba commented Jun 13, 2020

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 mikegerber changed the title Drop Python 3.5 support Things to do when dropping Python 3.5 support Jun 15, 2020
@mikegerber
Copy link
Member Author

mikegerber commented Jun 15, 2020

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
Copy link
Member Author

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)

mikegerber added a commit that referenced this issue Feb 28, 2022
The latest rapidfuzz updates broke Python 3.5 support. As it is EOL for some time now,
we are stopping testing with it.

See also gh-65 and gh-20.
@maxbachmann
Copy link
Contributor

@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
Copy link
Member Author

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

mikegerber added a commit that referenced this issue Mar 2, 2022
As of Python 3.6 we don't need to call str() on Path objects anymore.

See also gh-20.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants