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

add static type annotations #259

Merged
merged 1 commit into from
Apr 30, 2024
Merged

add static type annotations #259

merged 1 commit into from
Apr 30, 2024

Conversation

davidism
Copy link
Member

Add static type annotations and export them by adding the py.typed marker file. Passes mypy (strict), pyright (basic, strict is impossible), and pyright --verifytypes (checks that exported types are complete). Enables the tox "typing" env by default that runs all three checks, as well as testing in CI.

@davidism
Copy link
Member Author

This is the last of the big PRs. Along with #257 and #258, this now matches how other Pallets projects are organized.

@davidism davidism mentioned this pull request Apr 30, 2024
Copy link
Contributor

@macnewbold macnewbold left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great to me. Initially I was concerned for python 3.8 compatibility, but so far as I can tell, I think we're covered.

@macnewbold macnewbold merged commit 1d990e7 into main Apr 30, 2024
9 checks passed
@macnewbold macnewbold deleted the typing branch April 30, 2024 18:14
@davidism
Copy link
Member Author

from __future__ import annotations causes all annotations to be treated as strings initially by Python, so newer syntax and features will only be interpreted by static tools.

@jeffwidman
Copy link
Member

Do you plan to cut a new release now that these have landed to get the type annotations live?

Again, many thanks for all the great improvements here. I learned quite a bit just by reading through the PR's.

@davidism
Copy link
Member Author

I'll make a PR to demonstrate how the release workflow works, I think 0.16 is appropriate even though behavior didn't really change from 0.15. Maybe after that start thinking about what 1.0 might look like. 1.0 doesn't have to be perfect or zero inbox or anything like that, but this extension seems like it's stable and maintained at this point.

@jeffwidman
Copy link
Member

Sounds good.

We haven't done semver historically because it was just one more thing to have to worry about, but that friction is minimal now since it's a very stable/low-churn extension. We really haven't touched it much the last few years other than updating deprecations/dependencies.

Maybe even make do a 1.0 release instead of 0.16... this is as good a time as any... "now with type annotations!" 😄

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 15, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants