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.
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
Nonebut 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 withEnumValuefield, when buildingself.choices, see #2017.