Hi@RomuloOliveira, thanks for raising this. The docs do say thatrequired fields may be omitted:

Setting this toFalse also allows the object attribute or dictionary key to be omitted from output when serializing the instance. If the key is not present it will simply not be included in the output representation.

To address a few things...

However, it keeps the implicitdefault=None for required fields introduced in#5518.

To clarify, the PR description is not completely correct, and this was not the final behavior.default values affect both serialization and deserialization, andallow_null implyingdefault=None was not the correct behavior (you can see this in the commit/build history for#5518). Instead,allow_null only implies a default value forserialization output.

Did I wrote the test in the correct class (TestNotRequiredOutput) or should it be in theTestDefaultOutput class?

TestNotRequiredOutput is correct, as this isn't testing thedefault argument.

Is there a reason that the implicit defaultNone value forallow_null is not in theField.get_default function?

Yes, this is related toallow_null implyingdefault=None not being the correct behavior.

Should I add to the documentation thatallow_null implicitly set adefault=None for required fields?

I don't think it's necessary for this PR. I'll address it separately.

In hindsight, while consistent with therequired docs, I don't think this is the correct behavior. I'm thinking thatallow_null should always imply a default serialization value, regardless of whether a field is required.

@RomuloOliveira, was there a specific reason why these fields needed to be omitted from the serialized output? It's not clear to me what behavior this is enabling.

@rpkilby I've made this to maderequired=False output consistent and simple (not required -> omitted from output, period) and restore this behaviour, which existed before 3.7.2.

In my opinion, it keeps things explicit and do not depend on any other flags combinations to work as expected. In this way, an user do not need to know allcaveats and special behaviour that occurs when flags are combined.

I noticed this because after upgrading to 3.7.2 some fields were not consistent with others in an API that I was developing and it took a lot of time to figure out what was causing it. I've thought at first it was a bug before seeing the discussion#5518.

I thought it's a bit weird thatallow_null=True implies a default serialization output. It is not consistent with python/DRF "philosophy" of keeping things simple and explicit.

This discussion was closed and so was#5518, but as an DRF user, I'm asked myself why use implicit values (which can interfere with another flags) and, why use itonly inallow_null. I think it made inconsistent, sinceallow_blank=True do not imply a blank default output and I really don't think it should.