-
-
Notifications
You must be signed in to change notification settings - Fork 621
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Remove attribute
parameter from fields
#1187
Comments
There could be cases where the attribute name is not a valid Python variable name. Currently, get_value first tries to access by index, then by attribute, so I assume something like class MySchema:
my-attribute = fields.Int() I don't have a real-life use case for that. Nor do I have a real-life use case for the "access by index" feature. |
@lafrech You can use class MySchema(Schema):
class Meta:
include = {
"my-attribute": fields.Int()
} |
There's some code in def test_list_field_respect_inner_attribute(self):
now = dt.datetime.now()
obj = DateTimeList([now])
field = fields.List(fields.Int(attribute='day'))
assert field.serialize('dtimes', obj) == [now.day] This use case can still be met by using def test_list_field_respect_inner_attribute(self):
now = dt.datetime.now()
obj = DateTimeList([now])
class DateTimeSchema(Schema):
day = fields.Int()
field = fields.List(fields.Pluck(DateTimeSchema, 'day'))
assert field.serialize('dtimes', obj) == [now.day] This seems like a more consistent API anyway. |
Ah, removing attribute would break use cases where you want multiple output fields based on a single attribute: class UserSchema(Schema):
created = fields.DateTime()
created_formatted = fields.DateTime(format='%Y-%m-%d', attribute='created', dump_only=True)
created_iso = fields.DateTime(format='iso', attribute='created', dump_only=True) |
This use case is met by `fields.List(fields.Pluck(...))` #1187 (comment)
This use case is met by `fields.List(fields.Pluck(...))` #1187 (comment)
This could be achieved using |
I guess, but that's awkward. It feels wrong to set arbitrary attributes on an object. |
It could make more sense just to discourage the use of |
With
data_key
to designate the serialized key and the field name to designate the deserialized attribute, I can't think of a use case forattribute
. Are there cases where the field name would need to be different from the deserialized attribute?h/t @taion
cc @lafrech @deckar01
The text was updated successfully, but these errors were encountered: