Allow for easier construction of serializable objects#309
Allow for easier construction of serializable objects#309LivInTheLookingGlass wants to merge 17 commits intomsgpack:masterfrom
Conversation
|
Unpacking in Cython mode now works as well, and I have edited my PR to u-msgpack-python to also check for a |
|
I don't like this API design. I don't want to require custom type extends ExtType. |
|
This does not require that at all. I think you misread. The idea is that you can define types this way and then not need to pass in an ext_hook afterwards. The idea is not to require all custom objects to be done that way. |
|
Also, an API based on the copyreg approach is not possible to express with type hinting, whereas this is |
I didn't meant using typereg. I meant register based approach without any subclasssing.
I don't want to add N approaches. I don't want to add and maintain API I don't like. |
This pull request is similar to vsergeev/u-msgpack-python#37 and has a fully compatible API.
This PR adds the ability to usefully inherit from ExtType. It changes three things:
In python3, you can have the pretty NamedTuple version by inheriting from an initially defined class. In python2, you can inherit from a function call to namedtuple(). In both cases, all that needs to happen is for the class to define a
type/codevariable, to define adatavariable/property, and to define an_unpackbmethod for msgpack to hook onto.This PR enables the following in Python 3
And the following in Python 2 or 3:
This also enables for more flexible serialization through the use of dynamically calculated data: