Skip to content
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

Closed
sloria opened this issue Apr 7, 2019 · 7 comments · Fixed by #1331
Closed

RFC: Remove attribute parameter from fields #1187

sloria opened this issue Apr 7, 2019 · 7 comments · Fixed by #1331

Comments

@sloria
Copy link
Member

sloria commented Apr 7, 2019

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 for attribute. Are there cases where the field name would need to be different from the deserialized attribute?

h/t @taion

cc @lafrech @deckar01

@lafrech
Copy link
Member

lafrech commented Apr 7, 2019

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 object['my-attribute'] is expected, but you couldn't write

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.

@sloria
Copy link
Member Author

sloria commented Apr 7, 2019

@lafrech You can use include for that use case:

class MySchema(Schema):
    class Meta:
        include = {
            "my-attribute": fields.Int()
        }

@sloria
Copy link
Member Author

sloria commented Apr 7, 2019

There's some code in List and Tuple to for accessing attributes on the inner objects. This test demonstrates the use case:

    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 fields.Pluck, though.

    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.

@sloria
Copy link
Member Author

sloria commented Apr 7, 2019

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)

sloria added a commit that referenced this issue Apr 7, 2019
This use case is met by `fields.List(fields.Pluck(...))`

#1187 (comment)
sloria added a commit that referenced this issue Apr 7, 2019
This use case is met by `fields.List(fields.Pluck(...))`

#1187 (comment)
@lafrech
Copy link
Member

lafrech commented Apr 7, 2019

removing attribute would break use cases where you want multiple output fields based on a single attribute

This could be achieved using pre_dump to duplicate the value.

@sloria
Copy link
Member Author

sloria commented Apr 7, 2019

This could be achieved using pre_dump to duplicate the value.

I guess, but that's awkward. It feels wrong to set arbitrary attributes on an object.

@taion
Copy link
Contributor

taion commented Apr 8, 2019

It could make more sense just to discourage the use of attribute (and instead recommend data_key) in most cases, just to make the effective API surface area smaller.

@sloria sloria added this to the 4.0 milestone Jun 23, 2019
sloria added a commit that referenced this issue Aug 2, 2019
As pointed out in #1187, `attribute` should only be used in very
specific cases. Most of the time, you should use `data_key`.

close #1187
@sloria sloria added the docs label Aug 2, 2019
@sloria sloria removed this from the 4.0 milestone Aug 2, 2019
sloria added a commit that referenced this issue Aug 2, 2019
As pointed out in #1187, `attribute` should only be used in very
specific cases. Most of the time, you should use `data_key`.

close #1187
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants