[RFC] Don't pass attr, obj, data to fields (de)serialize methods

[lafrech]

From a quick look, those are not used by existing fields. I suspect this might be or have been useful in specific fields such as Method.

I can't investigate this thoroughly right now and anyway that would be a breaking change, but opening this here for discussion.

For separation of concerns, (de)ser methods shouldn't need the parent obj/data and field name.

Also, this means that one needs an object and a field name to serialize some data with a field, which may not always be the case. They may pass None but then they don't respect the API (since it won't work with a field (de)ser method that actually relies on those). I faced this specific problem with EnumValue field, when building self.choices, see #2017.

[lafrech]

I gave it a quick look.

attr and obj are needed in serialize to get the value from the object.

In _serialize, deserialize and _deserialize, they seem to be only used by Function / Method fields, so removing those would allow us to simplify the implementation.

I guess some users rely on those fields. OTOH, if they didn't exist, I doubt we'd modify (de)ser methods to pass attr and obj just to add them.

I don't have a simple idea to replace those fields, though. pre_load/dump methods don't really answer because we don't want to modify the object. Unless we add some sort of proxy around the object but this sounds complicated.

[lafrech]

An option could be to remove Function and Method fields and add an argument or two to Field to allow the user to pass a custom function/method to get the value from the object. This function/method could be called from get_value. In fact, it would be a get_value override.

So it wouldn't be a field by itself but rather a customization of an existing field. There would be a benefit in terms of auto-documentation, since the type of the value would be known (the user may choose to use Field for a type-free value).

We could add this feature and deprecate Function and Method (as well as the use of attr and obj) in marshmallow 3.x.

---

I was thinking of opening another issue about moving get_value logic to the schema. The schema would just need to access the attribute attribute of the field. If we do what I describe above, the schema would also need to call the custom accessor (the function/method). It's not obvious to me where the logic should be, but I still find it strange to pass an obj, an accessor function, etc.

[lafrech]

We could add accessor parameter to Field.

class Field(FieldABC):
   def __init__(..., accessor,...):
        ...
        self.get_value = accessor
        ...

Allowing the user to do that:

def ser_function(...):
    ...

class MySchema(Schema):

    def ser_method(...):
        ...

    # Deprecated
    old_function = fields.Function(ser_function)
    # Replace with
    new_function = fields.Field(accessor=ser_function)

    # Deprecated
    old_method = fields.Method(ser_method)
    # Replace with
    new_method = fields.Field(accessor=ser_method)

[lafrech]

I still need to get my head around this. If Function/Method/Constant used serialize rather than _serialize, we could remove the _CHECK_ATTRIBUTE hack.

But then we wouldn't call get_value so the simple solution above wouldn't work.

Also, it is worth noting that fields working at get_value level couldn't be embedded in container fields, as those are meant to pass the value, not the object (according to this issue and #1995 (comment)). Perhaps we can live with this limitation. I don't see the point of using such a field in a container field.

[lafrech]

Function / Method / Constant address two use cases.

• 1/ Define custom fields as one-liners. This is by no means necessary but can arguably be desired.
• 2/ Define fields that access the value from the object in a fancy way. This is what requires passing attr and obj.

We could keep Function and Method for case 1 without passing attr and obj. Or even decide that defining a custom field the normal way is acceptable and drop them altogether.

Case 2 could be addressed by offering a way to pass custom accessors to any field constructor. We could even offer to define one for loading and one for dumping. As I wrote above, the user would benefit from the field being correctly typed and offering correct validation, etc.

This would separate access and (de)serialization concerns.

So basically,

• Function and Method would keep their ser/deser functions/methods but those would receive the value after it has been accessed and wouldn't access the object. This way, they would work correctly in container fields as well.

• Field would receive a get_value parameter to override the way the value is accessed from the object. Maybe even one for deserialization if we want to go further than what is possible today. serialization_getter and deserialization_getter.

• Constant could be addressed by any field of the right type with a custom accessor.

I think this may finally be the way to get this right. Thoughts welcome.