GithubHelp home page GithubHelp logo

Comments (3)

lafrech avatar lafrech commented on June 3, 2024

I don't see an explicit test for this. @sloria was this intended?

from marshmallow.

deckar01 avatar deckar01 commented on June 3, 2024

from_dict lets you use field names that would otherwise not be valid class attributes. The observed behavior is consistent with using dotted keys for data_key and attribute.

from marshmallow import Schema, fields


Test = Schema.from_dict({'foo.bar': fields.Str()})
schema = Test()
obj = schema.load({'foo.bar': 'baz'})
print('from_dict', 'load', obj)
data = schema.dump(obj)
print('from_dict', 'dump', data)


class Test(Schema):
    foo_bar = fields.Str(data_key='foo.bar', attribute='foo.bar')
schema = Test()
obj = schema.load({'foo.bar': 'baz'})
print('Schema', 'load', obj)
data = schema.dump(obj)
print('Schema', 'dump', data)
from_dict  load  {'foo': {'bar': 'baz'}}
from_dict  dump  {'foo.bar': 'baz'}

Schema     load  {'foo': {'bar': 'baz'}}
Schema     dump  {'foo.bar': 'baz'}

This behavior is not documented for attribute thought. It appears to be a side effect of performing dotted name resolution in get_value at load time.

A workaround would be to explicitly define an attribute for the field without dots so that no nesting occurs.

from marshmallow import Schema, fields


Test = Schema.from_dict({'foo.bar': fields.Str(attribute='foo_bar')})
schema = Test()
obj = schema.load({'foo.bar': 'baz'})
print('from_dict', 'load', obj)
data = schema.dump(obj)
print('from_dict', 'dump', data)


class Test(Schema):
    foo_bar = fields.Str(data_key='foo.bar', attribute='foo_bar')
schema = Test()
obj = schema.load({'foo.bar': 'baz'})
print('Schema', 'load', obj)
data = schema.dump(obj)
print('Schema', 'dump', data)
from_dict  load  {'foo_bar': 'baz'}
from_dict  dump  {'foo.bar': 'baz'}

Schema     load  {'foo_bar': 'baz'}
Schema     dump  {'foo.bar': 'baz'}

from marshmallow.

deckar01 avatar deckar01 commented on June 3, 2024

This is an intentional behavior and it is covered with tests for attribute. See #450.

It is tempting to start adding ways to opt out of this behavior, but I don't think it is actually necessary to support arbitrary key structures in deserialized objects. If something is consuming the data and dictating the key structure, it should be consuming dumped data. Otherwise the code can conform to the default output or customize it with enveloping.

We should update the docs for attribute and from_dict to advertise this behavior.

from marshmallow.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.