Add support for deserialization #2

maroux · 2015-06-03T18:56:44Z

Added support for read-only fields
Renamed .data to .representation (and added .internal_value) for better clarity
Renamed .to_value to .to_representation (and added to_internal_value) for better clarity

TBD update documentation, fix benchmarks, update benchmarks

Fixes #1

- Added support for read-only fields - Renamed `.data` to `.representation` (and added `.internal_value`) for better clarity - Renamed `.to_value` to `.to_representation` (and added `to_internal_value`) for better clarity TBD update documentation, fix benchmarks, update benchmarks Fixes clarkduvall#1

clarkduvall · 2015-06-03T19:15:28Z

thanks for the pr! will take a look tonight at it

coveralls · 2015-06-03T19:38:10Z

Coverage remained the same at 100.0% when pulling 6d7fcaf on maroux:deserialization into 3663aaf on clarkduvall:master.

clarkduvall · 2015-06-03T19:49:15Z

quick high level comment:
I like the idea of having a similar API to DRF serializers using .to_representation and .to_internal_value now that both serialization and deserialization is supported. Along with that, I would like to keep .data instead of .representation, since it will be an easier drop in replacement for DRF.

clarkduvall · 2015-06-04T04:53:51Z

serpy/fields.py

        if method_name is None:
            method_name = 'get_{0}'.format(serializer_field_name)
-        return getattr(serializer_cls, method_name)
+        return getattr(serializer_cls, method_name, None)


i would rather not specify the default to getattr and have these methods fail if method_name doesn't exist

clarkduvall · 2015-06-04T05:23:35Z

It looks like DRF uses update/create/save for deserialization: http://www.django-rest-framework.org/api-guide/serializers/#saving-instances
and Marshmallow uses make_object: http://marshmallow.readthedocs.org/en/latest/quickstart.html#deserializing-to-objects

I'm thinking something like that would be nicer than the _cls class variable. What do you think of a make_object method like Marshmallow?

clarkduvall · 2015-06-04T05:31:45Z

serpy/serializer.py


-    def __init__(self, obj=None, many=False, **kwargs):
+    def __init__(self, obj=None, data=None, many=False, **kwargs):


what do you think about allowing an instance of a serializer to either serialize or deserialize, but not both. This could have one obj parameter like it was before, and it will either fill out self._representation or self._internal_value, and throw an exception if it tries to do both.

I don't particularly like overriding parameters that way: Serializer(instance_or_data=foo). But - I agree that by making a serializer do only one of serialization or deserialization would make it faster (eg. don't need to compile "write fields")

yeah, I like your proposal below about using instance for serialization and data for deserialization, lets go with that

clarkduvall · 2015-06-04T05:35:13Z

would be cool to add some benchmarks comparing the deserialization speed to DRF and Marshmallow, but that doesn't have to be in this PR

tomchristie · 2015-06-04T09:50:20Z

since it will be an easier drop in replacement for DRF.

Anything that'd make it easy to use as an alternative serializer implementation for REST framework would get a big +1 from me 😄

maroux · 2015-06-09T17:23:36Z

@clarkduvall @tomchristie Agreed that interface should be a drop-in replacement of DRF.

How about:

Serializer(instance=obj).data
and
Serializer(data=data).instance (this has to be slightly different because DRF 3.0 changed to explicitly using .create(validated_data). To be fair - Serpy could also do the same .create() does deserialization, but I like the property access pattern instead of method call.

Agreed on the _cls class variable. I wasn't sure what's the best way - perhaps Meta inner class? What do you think? I'm entirely sure about the impact of that on performance - I think it's time I set up the benchmarks :)

clarkduvall · 2015-06-09T17:56:55Z

@maroux I like the Serializer(instance=obj).data and Serializer(data=data).instance

I think it would be more flexible to have a function instead of just specifying the class for deserialization in case some extra massaging of the data has to be done before returning the instance. So if we had a make_instance function that takes the serialized data you could make the .instance property something like:

def make_instance(self, data):
  return SomeClass(**data)

@property
def instance(self):
  if self._instance is None:
    self._instance = self.make_instance(self.to_internal_value(self._data))
  return self._instance

by default make_instance could just be a noop

maroux · 2015-06-09T18:57:47Z

@clarkduvall So the problem with make_instance approach is two-fold: I think Serpy should do instance -> dict, and dict -> instance and since the default serializer is capable of taking in an object, I think it should also be able to create an object of arbitrary type.

How about this:

Serializer(instance=obj).data

and

Serializer(data=data).create(klass)

I'm not sure if there is value is setting a default value of klass to None, it would just return data as is? :/

maroux · 2015-06-09T18:59:50Z

Actually, disregard that suggestion, the Serializer(data=data).create(klass) approach will break nested serializers.

New API - `.data` and `.deserialized_value` Making `cls` a kwarg in `Serializer` instead of attribute

maroux · 2015-06-11T02:42:58Z

@clarkduvall What do you think about #3?

I'm now inclined to go back to the Meta inner-class approach that will allow us customize the serializer behavior cleanly.

clarkduvall · 2015-06-11T04:19:06Z

Yeah I think as more features are added the Meta inner class will be better. Lets do that, we can also move default_getter and default_setter to the Meta class

…done automatically

clarkduvall · 2015-06-11T23:52:51Z

README.rst

@@ -79,11 +79,11 @@ Simple Example
        z = serpy.Field()

    f = Foo(1)
-    FooSerializer(f).data
+    FooSerializer(f).representation


change these back to .data

clarkduvall · 2015-06-12T00:04:18Z

I still want a make_object function instead of doing cls() and setting attributes on it. I think by default the deserialized output should be a dict, and users shouldn't need to specify any class so we don't assume too much about what the final deserialized output will be. If they want it in class form, they can use the make_object method.

maroux · 2015-06-12T00:20:49Z

@clarkduvall I'm confused, wouldn't make_object become no-op in default case then since it's input is already a dict? :/

clarkduvall · 2015-06-12T00:30:58Z

yep, by default it would be a no-op unless you override it to return a class, see marshmallows implementation: https://github.com/marshmallow-code/marshmallow/blob/c4330c80073811bc175ffead89fe3cdc91797421/marshmallow/schema.py#L587-L595

For example to override it for a Django User model:

def make_object(self, data):
    return User(**data)

then when you do serializer.deserialized_data it will return a User object

maroux · 2015-06-12T00:40:00Z

I see what you mean. What's your thought on keeping it no-op in the default implementation, but have another serializer that lets you pass in cls?

clarkduvall · 2015-06-12T00:42:50Z

@maroux can you give me an example of what you mean?

squamous · 2015-10-01T03:55:15Z

I just came across this great library. Deserialization would be a big win - I can't really contribute much at this point besides my gratitude.

ngaurav · 2016-04-18T19:45:39Z

I would be really thankful if deserialization compatible with DRF is implemented.

bikeshedder · 2016-07-04T13:02:51Z

I'm using serpy in one of my projects and now I have to use DRF for deserialization and serpy for serialization. Having to define the same schema twice is rather unconvenient. Are there any plans when deserialization is going to be supported?

+1 for the make_object method rather than calling cls() as it allows for structures like {"type": "Foo", title="BlahBlah"} and {"type": "Bar", "title"="Blurb"} where the first is serialized as Foo and the second as Bar object. Keep it stupid simple and provide hooks to customize object creation. I also think that it is a good idea to pass the deserializer context to make_object. Otherwise it would be impossible to deserializer something like {"payload_type": "Foo", "payload_data": {"title": "BlahBlah"}}. That's a thing DRF does not support but Marshmallow does.

clarkduvall · 2016-07-17T17:16:59Z

I don't have a lot of time to work on this now, but if someone wants to implement this (or @maroux wants to continue this PR) using the make_object interface that was discussed earlier, I would definitely take a look at it.

stuart23 · 2020-08-17T23:04:51Z

serpy/fields.py

-        # If to_value isn't a method, it must have been overriden.
-        if not isinstance(to_value, types.MethodType):
+            def to_internal_value(self, data):
+                return data


Wouldn't you still want to cast it back to int?

stuart23 · 2020-08-17T23:22:22Z

serpy/serializer.py

+
+    :param instance: The object or objects to serialize.
+    :param data: The data to deserialize.
+    :param klass: The class for instantiating the deserialized object


This doesn't seem to be used at all

Aniruddha Maru added 2 commits June 3, 2015 11:55

Fixing Flake8 errors

3df6e87

Aniruddha Maru added 3 commits June 3, 2015 12:16

Fixing tests on Python 2.6

ca17891

Ugh, tripped Flake8 again

c2bb0fe

Yet another fix for Python 2.6

6d7fcaf

clarkduvall reviewed Jun 4, 2015
View reviewed changes

Some changes -

42d82b9

New API - `.data` and `.deserialized_value` Making `cls` a kwarg in `Serializer` instead of attribute

Aniruddha Maru added 2 commits June 11, 2015 10:05

Adding inner-class Meta

c8b4753

Meta inner-class doesn't have to inherit from parents - it should be …

1a892ec

…done automatically

clarkduvall reviewed Jun 11, 2015
View reviewed changes

Updating documentation

f12cdc2

stuart23 approved these changes Aug 17, 2020

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support for deserialization #2

Add support for deserialization #2

maroux commented Jun 3, 2015

clarkduvall commented Jun 3, 2015

coveralls commented Jun 3, 2015

clarkduvall commented Jun 3, 2015

clarkduvall Jun 4, 2015

maroux Jun 9, 2015

clarkduvall commented Jun 4, 2015

clarkduvall Jun 4, 2015

maroux Jun 9, 2015

clarkduvall Jun 9, 2015

clarkduvall commented Jun 4, 2015

tomchristie commented Jun 4, 2015

maroux commented Jun 9, 2015

clarkduvall commented Jun 9, 2015

maroux commented Jun 9, 2015

maroux commented Jun 9, 2015

maroux commented Jun 11, 2015

clarkduvall commented Jun 11, 2015

clarkduvall Jun 11, 2015

clarkduvall commented Jun 12, 2015

maroux commented Jun 12, 2015

clarkduvall commented Jun 12, 2015

maroux commented Jun 12, 2015

clarkduvall commented Jun 12, 2015

squamous commented Oct 1, 2015

ngaurav commented Apr 18, 2016

bikeshedder commented Jul 4, 2016

clarkduvall commented Jul 17, 2016

stuart23 Aug 17, 2020

stuart23 Aug 17, 2020


		def __init__(self, obj=None, many=False, **kwargs):
		def __init__(self, obj=None, data=None, many=False, **kwargs):

Add support for deserialization #2

Are you sure you want to change the base?

Add support for deserialization #2

Conversation

maroux commented Jun 3, 2015

clarkduvall commented Jun 3, 2015

coveralls commented Jun 3, 2015

clarkduvall commented Jun 3, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

clarkduvall commented Jun 4, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

clarkduvall commented Jun 4, 2015

tomchristie commented Jun 4, 2015

maroux commented Jun 9, 2015

clarkduvall commented Jun 9, 2015

maroux commented Jun 9, 2015

maroux commented Jun 9, 2015

maroux commented Jun 11, 2015

clarkduvall commented Jun 11, 2015

Choose a reason for hiding this comment

clarkduvall commented Jun 12, 2015

maroux commented Jun 12, 2015

clarkduvall commented Jun 12, 2015

maroux commented Jun 12, 2015

clarkduvall commented Jun 12, 2015

squamous commented Oct 1, 2015

ngaurav commented Apr 18, 2016

bikeshedder commented Jul 4, 2016

clarkduvall commented Jul 17, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment