You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Well, I know for a fact that this is incorrect. Unpacking methods accept any object that implements the buffer protocol, so next to bytes there's also bytearray, array, memoryview, numpy.ndarray, etc. There is a long-standing issue to add the ability to describe things as "buffer-like". It's an open issue, because buffers are very variable (writeable or not, data types, contiguous or non-contiguous, strided) and you need to describe them pretty accurately so your type annotation is actually useful.
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.
Reacted by Rodrigo Girão Serrão and Shahriar Heidrich
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.
Activity
methane commentedon Dec 11, 2020
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.
methane commentedon Jan 27, 2021
See #404.
sbdchd commentedon Jan 27, 2021
I ended up creating a separate type stub package: http://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?
http://github.com/python/typeshed/
jfolz commentedon Mar 19, 2021
Well, I know for a fact that this is incorrect. Unpacking methods accept any object that implements the buffer protocol, so next to
bytesthere's alsobytearray,array,memoryview,numpy.ndarray, etc. There is a long-standing issue to add the ability to describe things as "buffer-like". It's an open issue, because buffers are very variable (writeable or not, data types, contiguous or non-contiguous, strided) and you need to describe them pretty accurately so your type annotation is actually useful.rodrigogiraoserrao commentedon Feb 17, 2023
It's been almost 2 years but a comment on the linked issue says PEP 688 is here to save the day.
Was that the thing that we needed to unblock this?
jfolz commentedon Feb 18, 2023
Well, for one a PEP needs to be accepted and implemented first to make a difference. As of now it's just a draft.
rodrigogiraoserrao commentedon Feb 18, 2023
Ugh, sorry. Got so carried away by it that I didn't even check the PEP status.
jfolz commentedon Mar 10, 2023
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.
clokep commentedon May 30, 2023
typing-extensions now supports
Bufferin the latest release, this is a common way to backport new typing PEPs to projects.rexzhang commentedon Mar 6, 2025
The return value of msgpack.packb is bytes, which can reduce many warnings if it is type-annotated.