Skip to content
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

Open
sbdchd opened this issue Dec 11, 2020 · 9 comments
Open

Adding type stubs #448

sbdchd opened this issue Dec 11, 2020 · 9 comments

Comments

@sbdchd
Copy link

sbdchd commented Dec 11, 2020

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/

@methane
Copy link
Member

methane commented Dec 11, 2020

Would you accept a PR adding stub files to the package?

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
Copy link
Member

methane commented Jan 27, 2021

See #404.

@sbdchd
Copy link
Author

sbdchd commented Jan 27, 2021

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?

https://github.com/python/typeshed/

@jfolz
Copy link
Contributor

jfolz commented 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 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.

@rodrigogiraoserrao
Copy link

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
Copy link
Contributor

jfolz commented 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
Copy link

Ugh, sorry. Got so carried away by it that I didn't even check the PEP status.

@jfolz
Copy link
Contributor

jfolz commented 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
Copy link

clokep commented May 30, 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.

typing-extensions now supports Buffer in the latest release, this is a common way to backport new typing PEPs to projects.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants