This PR is pretty large, to say the least, because it introduces linting (using pylint) and static checking (using mypy - previously, I was going to use pyright). To introduce linting and static checking for PRs, you need to fix all of the issues that it flags. This happened to be a lot issues because during the development of v3 of this SDK, style (aka linting) and certain type checks (aka mypy) was lacking intentionally in order to meet the timeline for release. Since python is pretty forgiving in the type check department, we deferred that until now.
The user can test their compliance with pylint and mypy locally by invoking the same process used in the GitHub actions as follows:
this introduces 2 new GitHub actions to check for pylint and mypy issues for new PRs and on main
observes python best practices to use _ for class scoping
(THIS HAPPENED TO BE A LARGE PART OF THE CHANGES IN THIS PR) had to change @dataclass_json annotations (now just extends the DataClassJsonMixin class in dataclass_json because the project doesn't implement a pylint plugin for linting
for all the Latest classes, these just needed to be alias definitions instead of extending the class since the linter through that was better (agreed because we weren't introducing any new variables, functions, etc)
NOTES:
These changes should NOT be breaking changes.
Ran all examples in order to verify nothing, in fact, has changed.
Will refactor a little in a subsequent PR for functions that duplicate a lot of code. Currently, there are some disable pylint and mypy checks for certain functions to make sure the functionality/behavior of the SDK doesn't change.
Types of changes
What types of changes does your code introduce to the community Python SDK?
Put an x in the boxes that apply
[ ] Bugfix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation update or tests (if none of the other choices apply)
Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.
Proposed changes
Implements: https://github.com/deepgram/deepgram-python-sdk/issues/390
This PR is pretty large, to say the least, because it introduces linting (using
pylint) and static checking (usingmypy- previously, I was going to usepyright). To introduce linting and static checking for PRs, you need to fix all of the issues that it flags. This happened to be a lot issues because during the development of v3 of this SDK, style (aka linting) and certain type checks (aka mypy) was lacking intentionally in order to meet the timeline for release. Since python is pretty forgiving in the type check department, we deferred that until now.The user can test their compliance with
pylintandmypylocally by invoking the same process used in the GitHub actions as follows:make lintmake staticGitHub actions run for this PR:
Other notable changes:
pylintandmypyissues for new PRs and on main_for class scoping@dataclass_jsonannotations (now just extends theDataClassJsonMixinclass indataclass_jsonbecause the project doesn't implement apylintplugin for lintingLatestclasses, these just needed to be alias definitions instead of extending the class since the linter through that was better (agreed because we weren't introducing any new variables, functions, etc)NOTES:
Types of changes
What types of changes does your code introduce to the community Python SDK? Put an
xin the boxes that applyChecklist
Put an
xin the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.Further comments
NA