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

tuple and list are indistinguishable #98

Closed
faerot opened this issue May 14, 2014 · 3 comments · Fixed by #158
Closed

tuple and list are indistinguishable #98

faerot opened this issue May 14, 2014 · 3 comments · Fixed by #158

Comments

@faerot
Copy link
Contributor

faerot commented May 14, 2014

I am trying to build universal serializaion system on top of msgpack, similar to standard pickle, except more secure. The system needs to be accurate at saving/restoring data.

The problem is current implementation stores list and tuple as sequence and type information is lost on loading it back. Unfortunately it is impossible to treat tuple and list differently in current version of the library and while it is trivial to fix, it requires altering msgpack.

What is needed is extra argument to Packer. Something like tuple_autoconvert=False. If this argument is set, msgpack would not serialize tuple as list, but treat it as unknown type and will pass it's serialization to default. This way it would be possible to implement custom serialization to tuple via extension type, etc.

@campagnola
Copy link

I'd love to have this option as well.

@pallas
Copy link

pallas commented May 4, 2019

Why not convert tuples to fixarray and arrays to array?

@filmor
Copy link

filmor commented May 4, 2019

fixarray and array are semantically the same thing in msgpack, the fix just means that the length (up to 15) is encoded directly in the leading byte, see https://github.com/msgpack/msgpack/blob/master/spec.md#array-format-family.

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

Successfully merging a pull request may close this issue.

5 participants