-
Notifications
You must be signed in to change notification settings - Fork 21
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
feat: Add type hints #256
feat: Add type hints #256
Conversation
Thanks for the pull request, @bradenmacdonald! As a core committer in this repo, you can merge this once the pull request is approved per the core committer reviewer requirements and according to the agreement with your edX Champion. |
a9a7c3f
to
1bce0d3
Compare
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## master #256 +/- ##
==========================================
+ Coverage 94.07% 94.12% +0.04%
==========================================
Files 29 29
Lines 2837 2860 +23
Branches 292 292
==========================================
+ Hits 2669 2692 +23
+ Misses 143 142 -1
- Partials 25 26 +1
Flags with carried forward coverage won't be shown. Click here to find out more.
☔ View full report in Codecov by Sentry. |
@felipemontoya @pdpinch would one of you be able to review this PR for me? |
pickleable_dict[key] = getattr(self, key) | ||
pickleable_dict['deprecated'] = self.deprecated | ||
return pickleable_dict | ||
|
||
@property | ||
def _key(self): | ||
def _key(self) -> tuple: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it worthwhile (or even possible) to include the subtypes of the tuple returned?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice, but I don't think it's even possible, as the number of fields in the tuple depends on the KEY_FIELDS
of the subclass. The type isn't tuple[str, ...]
either, as some of the "key field" values are actually ObjectId
type, not strings.
I'm not well versed with the type hints. I don't think I would be a good reviewer but I'm glad to see the PR is being reviewed now. |
@pdpinch would you be able to approve this one? |
Thanks for your review, @blarghmatey :) |
…ity) Also the version of pep8 was so old, it didn't understand type hints
Thanks for the pull request, @bradenmacdonald! Please note that it may take us up to several weeks or months to complete a review and merge your PR. Feel free to add as much of the following information to the ticket as you can:
All technical communication about the code itself will be done via the GitHub pull request interface. As a reminder, our process documentation is here. Please let us know once your PR is ready for our review and all tests are green. |
@felipemontoya or @pdpinch would one of you be comfortable approving this based on @blarghmatey's review? Sorry to ping multiple times here, but you two are the only CCs for this repo so I'm not sure how to move it forward otherwise. |
Yes. I actually learned a lot about type hints while following this PR |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on the review by @blarghmatey and the inclusion of mypy as part of the test suite this looks good to me.
Thanks @bradenmacdonald for the update to using type hints.
@bradenmacdonald 🎉 Your pull request was merged! Please take a moment to answer a two question survey so we can improve your experience in the future. |
Thanks @felipemontoya ! |
This adds type hints to opaque-keys, including to the CI build so that type rules are enforced before PRs can be merged.
This is actually aimed to help with edx-platform development, because once these type hints are in place, mypy can be used to check types of modules in edx-platform - see openedx/edx-platform#32591 for example. Currently mypy just treats any OpaqueKey type as
Any
which is not helpful.Some of the variables are of type
ObjectId
but this gets broadened automatically toAny
because we're using an old version ofpymongo
that lacks type annotations. Once we upgradepymongo
, we'll have a more specificObjectId
type working.Left for future:
pymongo
so we have a workingObjectId
type