Consistency with allow_none with serialization and deserialization

[matejsp]

I saw already comments how to workaround this issue:
#229 (comment)
#229 (comment)

But still I would like to marshmallow to be consistent with itself.

Basically you have a schema with allow_none=False and after dumping it you cannot load it back (without manually fixing the output that is not correct according to schema).

import marshmallow

class TransferSchema(marshmallow.Schema):
    id = marshmallow.fields.Int(allow_none=False)
    str = marshmallow.fields.Str(allow_none=False)


x = TransferSchema()
dumped = x.dump({
    'id': None,
    'str': None,
})

print(dumped)
loaded = x.load(dumped)
print(loaded)

error:

marshmallow.exceptions.ValidationError: {'id': ['Field may not be null.'], 'str': ['Field may not be null.']}

I think allow_none should be respected for both on serialize and deserialize.

[Praveenkumar76]

Hi @matejsp @svenstaro @EdwardBetts @pc-m @kalasjocke,

I'm looking to put together a PR to resolve this long-standing inconsistency with allow_none during serialization (dump()).

As pointed out, post_dump hooks are flawed because they aggressively strip all None values, even for fields where allow_none=True.

Before I open a PR, I want to make sure I align with the maintainers' preferred approach, as changing dump() behavior is a breaking change. Which of these three directions would you prefer for the next major release?

1. Strict validation (like load): dump() raises a ValidationError if it encounters a None on a field with allow_none=False.
2. Silent stripping: dump() silently excludes the field/key from the output dictionary entirely.
3. Opt-in strictness: We introduce a new Meta option (e.g., strict_dump_none=True) to enforce consistency without breaking backward compatibility for existing users.

Let me know which path you prefer and I'll gladly author the fix!