Fix case where string encoding overhead is larger than needed #108
Conversation
According to the spec "serializers SHOULD use the format which represents the data in the smallest number of bytes". This is not true for strings between 32 and (2^8)-1 bytes which has an encoding overhead of 3 bytes instead of the required 2. My guess is that the somewhat strange conditional in fallback.py:598 (and cython equivalent) is to make sure that old raw type test cases in test_case.py that test for encoding overhead succeeds. This commit updates the test case to test for the encoding overhead for both str and bin types of various lengths.
|
str8 is introduced later with bin types. See also: msgpack/msgpack#183 |
|
@methane I think that this patch is indicative of a communication problem that msgpack has with new arrivals to the community. (It is somewhat ironic that you reference the spec rewording that I myself wrote, after having understood what the old one meant) I needed an efficient simple data serialisation format, and based on the information on msgpack.org I assumed that the referenced spec was what the various implementations would implement. This is not the case, and figuring that out requires a lot of digging. When can we expect a major version upgrade of the python implementation, that implements the spec as written? |
2 participants
According to the spec "serializers SHOULD use the format which
represents the data in the smallest number of bytes". This is not true
for strings between 32 and (2^8)-1 bytes which has an encoding
overhead of 3 bytes instead of the required 2.
My guess is that the somewhat strange conditional in fallback.py:598
(and cython equivalent) is to make sure that old raw type test
cases in test_case.py that test for encoding overhead succeeds.
This commit updates the test case to test for the encoding overhead
for both str and bin types of various lengths.