-
Notifications
You must be signed in to change notification settings - Fork 167
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
Adoption of type-hints #541
Comments
I have no strong opinion on this matter but I am worried about the extra maintenance effort. How would you benefit from cloudpickle using type-hints? Do you use cloudpickle as a library in another library that uses type-hints? |
Having cloudpickle in any type-verified project (e.g. using mypy) results in errors like
forcing you to add cloudpickle to type-ignore list in pyproject.toml, which isn't nice. Also, having type annotations in the library itself may prevent some downstream user errors (e.g. they will have their ide/editor highlight type mismatches if any). |
I don't think there's too much maintenance effort - it's basically adding type annotations around all public-facing functions/methods/types, and then adding an empty For bonus points, you'd want to run |
Agree with @aldanor, he explained my current issues. I am adding |
We can indeed start with a minimal PR that adds type annotations to the public API of cloudpickle only and later decide if we want to generalize type annotations to private functions/methods for follow-up PRs. If there are any volunteer in the room, feel free to open a PR for the first part. |
The adoption of type-hints is becoming popular in the python community. Are there plans to add type hints within cloudpickle?
The text was updated successfully, but these errors were encountered: