python-desert / desert

Deserialize to objects while staying DRY
https://desert.readthedocs.io
MIT License
158 stars 10 forks source link

define a way to easily provide data_key without breaking the bank #232

Open mmerickel opened 1 year ago

mmerickel commented 1 year ago

A really common use-case I've run into in my codebase is that our raw data schemas use hyphens - thus not mapping directly to a python identifier. In these cases we need to specify data_key and when we do that, we have to break out and define the entire marshmallow field ourselves, losing all the great stuff desert does for us. I'd love to see desert.field, desert.ib, and desert.metadata extended to support data_key= to forward along to the underlying type, as well as potentially other standard field options if applicable. The other two that stand out to me are validate and error_messages. I acknowledge that this is a slippery slope but maybe it'd make sense for those APIs to just forward **kwargs to the underlying field, and potentially to even error on kwargs if a field is passed in. Were there other use cases of kwargs on those APIs that this would conflict with? If so, we could define a marshmallow_field_args arg instead to disambiguate, alongside the existing marshmallow_field positional?

@dataclass
class Parent:
    name: str = desert.field(mm.fields.Str(data_key='userid', required=True))

vs

@dataclass
class Parent:
    name: str = desert.field(data_key='userid')

I'm happy to contribute a PR if I can get some confidence that this will be accepted design-wise.