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

Drop support for Python 3.9 #130

Merged
merged 6 commits into from
Dec 11, 2024
Merged

Drop support for Python 3.9 #130

merged 6 commits into from
Dec 11, 2024

Conversation

binaryDiv
Copy link
Contributor

This PR removes support for Python 3.9, raising the minimum Python version to 3.10, in order to allow for more modern typing (union types with X | Y), and modernizes the code base.

Additionally, this allowed us to remove a rather hacky workaround that was needed for Python < 3.10, where dataclasses did not support kw_only yet. This also removes the need for coverage-conditional-plugin.

I also updated the testing dependencies.

This qualifies as a breaking change in terms of Python version compatibility. There are no breaking API changes, however.

@binaryDiv binaryDiv added breaking changes This issue will cause a breaking change (or deprecation warning). refactoring Code refactoring, clean up and other code maintenance work. labels Dec 10, 2024
@binaryDiv binaryDiv self-assigned this Dec 10, 2024
@JGaukrogers
Copy link

I see no changes in the file validataclass_mixin_test.py, but there is the method test_create_with_defaults_invalid_required_fields, which contains the comment # The exact exception message changed between Python versions 3.9 and 3.10. Now I am wondering if there needs to be adapted something, or if we can leave it as it is.

@binaryDiv
Copy link
Contributor Author

@JGaukrogers

I see no changes in the file validataclass_mixin_test.py, but there is the method test_create_with_defaults_invalid_required_fields, which contains the comment # The exact exception message changed between Python versions 3.9 and 3.10. Now I am wondering if there needs to be adapted something, or if we can leave it as it is.

Well spotted! :D

I was thinking about changing that too, but I don't think it's really worth changing. For one thing, just partially matching the error message is sufficient I think, and also it's a test for a deprecated function that will be removed soon, anyway.

(Actually, I think it's probably a good time to remove it in the upcoming release, it's been deprecated for a while and I don't think it's still used anywhere in our projects... But that's for another PR ^^)

@binaryDiv binaryDiv merged commit 0774c36 into main Dec 11, 2024
5 checks passed
@binaryDiv binaryDiv deleted the drop-python39-support branch December 11, 2024 15:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking changes This issue will cause a breaking change (or deprecation warning). refactoring Code refactoring, clean up and other code maintenance work.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants