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.
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_keyand 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 seedesert.field,desert.ib, anddesert.metadataextended to supportdata_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 arevalidateanderror_messages. I acknowledge that this is a slippery slope but maybe it'd make sense for those APIs to just forward**kwargsto 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 amarshmallow_field_argsarg instead to disambiguate, alongside the existingmarshmallow_fieldpositional?vs
I'm happy to contribute a PR if I can get some confidence that this will be accepted design-wise.