I'm not sure if I'm missing something, but I would like to throw error if extra keys are provided, as in:

>>> class AlbumSchema(Schema):
...     title = fields.Str()

>>> AlbumSchema(strict=True).load({'extra': 2}, allow_extra=False)
Traceback (most recent call last):
...
marshmallow.exceptions.ValidationError: {'_schema': ["Extra arguments passed: ['extra']"]}

I've been using the following implementation (taken from https://github.com/sloria/webargs/issues/87#issuecomment-183949558):

class BaseSchema(Schema):

    @pre_load
    def validate_extra(self, in_data):
        if not isinstance(in_data, dict):
            return

        extra_args = [key for key in in_data.keys() if key not in self.fields]
        if extra_args:
            raise ValidationError('Extra arguments passed: {}'.format(extra_args))

I would expect this to be a common need, however, so could it be supported by the library out-of-the-box?

Often, validators and preprocessors only apply to a single Schema, so it may make sense to define them within the Schema--rather than as separate functions--for better cohesion.

Method names could be passed to __validators__, et. al, like so:

class UserSchema(Schema):
    __validators__ = ['validate_schema']

    def validate_schema(self, data):
        # ...

This is a rework of #595 so that it supports the API discussed in #524.

By default, only the fields described in the schema are returned when data is deserialized.

This commit implements an unknown option, so that Schema(unknown=ALLOW) or Schema().load(data, unknown=ALLOW) permit users to receive the unknown fields from the data.

Schema(unknown=RAISE) or Schema().load(data, unknown=RAISE) will raise a ValidationError for each unknown field.

Schema(unknown=IGNORE) or Schema().load(data, unknown=IGNORE) keep the original behavior.

Edit: ALLOW will finally be INCLUDE, and IGNORE will be EXCLUDE.

Suggested earlier here: https://github.com/marshmallow-code/marshmallow/issues/19#issuecomment-43685498.

The suggestion would be to allow:

foo = fields.Nested(lambda: Foo)

in addition to

foo = fields.Nested('Foo')

Seems a bit cleaner in general.

This allows to specify a nested only parameter both at schema instantiation time and during dump() like so:

class ChildSchema(Schema):
    foo = fields.Field()
    bar = fields.Field()
    baz = fields.Field()

class ParentSchema(Schema):
    bla = fields.Field()
    bli = fields.Field()
    blubb = fields.Nested(ChildSchema)

data = dict(bla=1, bli=2, blubb=dict(foo=42, bar=24, baz=242))

# either when instantiating
sch = ParentSchema(only=('bla', ('blubb', ('foo', 'bar'))))
result = sch.dump(data)

#or when dumping
sch = ParentSchema()
result = sch.dump(data, only=('bla', ('blubb', ('foo', 'bar'))))

It is fully backwards compatible. Fixes #402

When dumping, I want to manipulate some of the attributes on the object being dumped before actually dumping. So I decorate a preprocessor function. But that only gets used when loading. I could use a Method field, but the data returned from that must be the final serialized form, so there's no way to specify that it's actually a Nested(OtherSchema, many=True) unless I do that serialization manually at the end of the method.

When loading, I want to manipulate the loaded data in the exact opposite direction as the situation above. So I decorate a data_handler function. But that only gets used when dumping. The solution is more straightforward here: I override the make_object method to manipulate the final output.

My point is that the names are different everywhere, some of them are decorators while others are methods, and they don't apply in both directions, when it would be very convenient to be able to do so. The loading situation is in better shape than the dumping one, since loading has preprocessor and make_object, except there's still a weird decorator vs. method difference.

There should be a standard way to preprocess and postprocess the entire data during both loading and dumping. One solution is adding pre_dump, post_dump, pre_load, and post_load hooks, either as methods on the schema or as decorators.

For a put request model require of id field, but for post request id not needed. For disabling in a post request I use dump_only=["id"], but I have not found such a way to do id required. For this reason, I suggest adding required to the schema constructor.

Hi. I've been digging around and couldn't find the answer to this.

Say I've got a model like this:

class AlbumSchema(Schema):
    year = fields.Int()

class ArtistSchema(Schema):
    name = fields.Str()
    albums = ...

I want albums to be a dict of AlbumSchema, so that ArtistSchema serializes as

{ 'albums': { 'Hunky Dory': {'year': 1971},
              'The Man Who Sold the World': {'year': 1970}},
  'name': 'David Bowie'}

Naively, I would expect syntaxes like this to work:

fields.List(Schema)
fields.Dict(Schema)

or maybe

fields.List(fields.Nested(Schema))
fields.Dict(fields.Nested(Schema))

Serializing a list of Schema can be achieved through Nested(Schema, many=True), which I find less intuitive, and I don't know about a dict of Schema.

Is there any way to do it? Or a good reason not to do it?

(Question also asked on SO.)

I have got some use cases where I use a Enum in my models.

Example:

# definitions.py
from enum import Enum

class Gender(Enum):
    male = 'm'
    female = 'f'

# models.py
from definitions import Gender

class Person:
    def __init__(self, gender: Gender):
        self.gender = gender

Now it would be great if I could use the Enum in marshmallow.fields.Select:

# schemas.py
from marshmallow import fields, Schema
from definitions import Gender
from models import Person

class PersonSchema(Schema):
    gender = fields.Select(Gender)

    @staticmethod
    def make_object(data) -> Person:
        return Person(**data)

For backwards-compatibility enum34 could be used.

Improves validation error reporting functionality enabling reporting field errors from whole-schema (validates_schema) validator.

Introduces new public function marshmallow.utils.merge_errors which allows deep merging of errors. It can be useful to simplify accumulating errors in users' validators.

Updates validation error documentation to clarify error messages format.

Fixes #441

This is a revival of https://github.com/marshmallow-code/marshmallow/pull/573

Unfortunately other personal/professional priorities prempted me from focusing on this for the past few months, but I'd like to revisit open sourcing this again.

When we deployed this to production we saw ~20x improvement in serialization time which, in turn, dropped our response times in half.

I totally understand the apprehension on the original PR due to the complexity this introduces, so I've created a follow on PR that integrates the hooks I need into marshmallow, leaving everything else relatively unchanged.

We're still able to get the same performance gains, and I'm able to iterate on my JIT library without having to pester you with PRs :D. If we can get this integration working we'll have an awesome story about how Marshmallow allows engineers to have the amazing API of Marshmallow without having to sacrifice performance.

Bumps sphinx from 5.3.0 to 6.0.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

This PR shows what it would look like if we used Python 3.11's improved fromisoformat (backported for older releases).

Less code on our side and it should be more efficient (C implementation).

(We could simplify even more by passing those functions directly to the class and remove everything from utils.py.)

There are 2 failing tests.

• "2018-01-01" is accepted as a datetime while it is currently rejected in marshmallow. I guess this would be a breaking change. We may keep the old behaviour with a temporary trick until marshmallow 4 (keep the regex or even just check input string length).

• Time deserialization respects timezones. It is not clear to me what a time with timezone but without date means. It could be ambiguous for timezones with DST. In any case, this can be considered either bugfix or breaking change, and it could be "fixed" to keep old behaviour.

Consider this as an RFC.

Meanwhile, anyone willing to do it in their app may set those functions as class attributes and use the backport if needed.

I have a quite big application that grows everyday and I begin to face performance problems both with network loading and sometimes in the frontend. I would therefore like to minimize some of the objects such that I don't pass the attributes if they are null.

from marshmallow import Schema, fields

class PersonSchema(Schema):
    id = fields.Number()
    name = fields.Str()
    child_dream_job = fields.Str(do_not_dump_if_null=True)


album = dict( id =1, name="test", child_dream_job=None)

schema = PersonSchema()
assert schema.dump(album) == {"id":1, "name":"test"}

So in typescript notation:

interface IPerson {
  id: number;
  name: string;
  child_dream_job? : string;
}

instead of

interface IPerson {
  id: number;
  name: string;
  child_dream_job : string | null;
}

I just got caught.

I wrote

    validate=validate.OneOf("one", "two")

instead of

    validate=validate.OneOf(["one", "two"])

"one" would pass because "one" in "one" is True.

It might save users trouble if we emitted a warning when a string is passed instead of a non-string iterable.

In practice, it only affects lists made of two elements (or one but users would use Equal), so no big deal.

Basically I would like to add a new nested relation to an schema, that I already use in other services, without this implying a change to the rest of the functionalities that use it for serialization. Since I work with sqlalchemy, if I include the new relation, new unwanted statements appears everywhere, since the ORM tries to fill it. I would need something like adding the relation, and specifying that be only included if I specify it. I seen this kind of problem resolved in other libraries using groups annotations, so in this case, the relation is added, annotated with a new group, and them call serialize using the existing groups plus the new one.

Note: Create a new schema is not a good solution since the affected schema is deep in the relation, so I would have to create all it's fathers too.