-
Notifications
You must be signed in to change notification settings - Fork 230
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
Adding type stubs #448
Comments
I expect it will be very complex types and very low benefit for users, because msgpack can pack/unpack various types. I don't want to maintain it. But if it is simple and very useful, I will consider it. |
See #404. |
I ended up creating a separate type stub package: https://github.com/sbdchd/msgpack-types If you aren't interested in have the types in the package itself, would you be okay with me adding them to the type shed? |
Well, I know for a fact that this is incorrect. Unpacking methods accept any object that implements the buffer protocol, so next to |
It's been almost 2 years but a comment on the linked issue says PEP 688 is here to save the day. |
Well, for one a PEP needs to be accepted and implemented first to make a difference. As of now it's just a draft. |
Ugh, sorry. Got so carried away by it that I didn't even check the PEP status. |
Good news is that PEP 688 has been accepted. Bad news is that it'll be available in Python 3.12 at the earliest. Any earlier version would need a backport. |
typing-extensions now supports |
In the course of using msgpack in a project I've written some basic type stubs for the parts of the API I'm using.
I don't think it would be too hard to fill out the type stubs for the rest of the API.
Would you accept a PR adding stub files to the package?
Not sure if you have a preference on adding the types to the code itself or keeping them as separate stub files.
related: https://www.python.org/dev/peps/pep-0561/
The text was updated successfully, but these errors were encountered: