Add missing_values parameter to Field

[sloria]

Proves the concept proposed in #713 (comment)

Still needs docs and details, but this is ready for review.

TODO:

• Respect missing_values on serialization? see discussion
• Update Field.__repr__ to include missing_values
• Docs

[sloria]

This test might not be necessary--it's sorta just testing the Python language. Just wanted to make sure this use case was met.

[lafrech]

LGTM.

Respect missing_values on serialization?

What would that do? I'm tempted to say no. Do we do anything specific with missing already?

[sloria]

It would make default value get returned for missing values on serialization.

from marshmallow import Schema, fields


class ArtistSchema(Schema):
    name = fields.Str(default="---", missing_values=("",))


sch = ArtistSchema()
print(sch.dump({}))   # =>  {'name': '---'}
print(sch.dump({"name": ""})) # => {'name': ''} now, but maybe should be same as above

Sure, it's not a common use case, but it seems inconsistent to not handle it.

[lafrech]

OK, I get it.

Maybe it shouldn't be the same parameter.

IIUC, the primary use case for this is an API for which it is complicated to enforce removal of empty-ish values. There is no reason the same constraint would apply to the serialized form of the data.

But the database may have its own constraint. When using SQL, I already felt the need to treat None as missing to avoid returning null (#229 (comment)) and your proposal would solve that. But I didn't want to treat null as missing when deserializing.

Symmetry would recommend default_values, although the name is a bit misleading.

[sloria]

That's a good point; the client inputs for "no data" may be different from the database's representation.

default_values is indeed misleading. If we go with #778 , we could do load_default_values and dump_default_values, I guess. Maybe we defer the serialization param for now.

[lafrech]

default_values is indeed misleading. If we go with #778 , we could do load_default_values and dump_default_values, I guess. Maybe we defer the serialization param for now.

#1742 is about to close #778.

We could then change the names here. And do the serialization part in here or another PR.