Yeah, this is a follow up for https://stackoverflow.com/questions/46849343/drf-3-7-0-removed-handling-none-in-fields-and-broke-my-foreign-key-source-fields

Aside from discussions about whether flags should imply default values, I'd just would like to point out that if a serializer declares a field then a key for that field should unconditionally exist in the serialized output. The referenced change broke this contract for the first time.

Although: I'd agree if this was rejected due to explicit vs implicit. Perhaps requiring a default to be declared in these cases?

@rpkilby What's the status here? I'm beginning to look at a 3.7.2 (say beginning of next week). Ta!

@carltongibson Basically, trying to figure out what the correct behavior should be here.

allow_null=True should not imply default=None. This was verified by test failures, where you may want to allow null values as input, but require this explicitly during deserialization.

That all said:

Aside from discussions about whether flags should imply default values, I'd just would like to point out that if a serializer declares a field then a key for that field should unconditionally exist in the serialized output. The referenced change broke this contract for the first time.

Is this contract actually true, or is it an assumption made as a result of the previous behavior? Pinging @tomchristie for input here.

At this point, I'm kind of leaning towards accepting the PR. It allows correct serialization of fields when no object relation exists. However, when coupled with required=True, a user must supply a value during deserialization.

Just as a followup from #5639..

I'd just would like to point out that if a serializer declares a field then a key for that field should unconditionally exist in the serialized output.
-- @rapilabs

This statement is true, except for non-required fields. Quoting from the Field.required docs:

Setting this to False 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.