Undocumented backwards incompatibility: DateField.to_native now returns a string instead of a date?

[benrobster]

This behavior seems to have changed over the past few weeks, because I had code that worked on 2.2.0 that assumed that the output of a serialized DateField was a date (or datetime) which is now broken because DateField.to_native now returns a string instead of a datetime.date. This appeared to have happened in 2.2.2 - "Support for custom input and output formats for DateField, DateTimeField and TimeField". However, I wonder whether the fact that this change is backwards-incompatible and possibly ill-advised was considered when the update was made. Isn't datetime.date a "native" type that gets handled just fine when rendered and wouldn't a date be the expected native type of the output of DateField.to_native? is_protected_type in encoding.py seems to indicate that dates should be preserved as-is when serialized, so there's a bit of a contradiction here, in addition to it being a undocumented backwards-incompatibility. I assume that the ability to do custom output formats for DateFields is important to some, but having access to an actual date instead of a string in a serialized object is important to others like myself. I wonder if there is a way to reconcile the two.

I'd be happy to jump in and fix things if I get some guidance here. If the old way (returning a date) was wrong, I guess I'll create my own custom field that returns a date like I would expect instead of string.

I guess this could arguably fall under "Note that in line with Django's policy, any parts of the framework not mentioned in the documentation should generally be considered private API, and may be subject to change" but I figured I'd bring it up anyway.

[tomchristie]

Yup bit of a gray area, but yees I think you're right that should have been more cautious on this one. :-/

I guess one option that could work for both sides would be to return a datetime if no format is explicitly set on the field, and have the renderer use the default format from the settings. (And only return a string formatted value from the field if a format is explicitly set.)

[tomchristie]

As you can guess, was assuming it wasn't a regression for anyone given the resulting output format is the same either way around, but evidently not true in your case.

[tomchristie]

@nebstrebor - If you get the chance to review #743 that'd be fab. Should do what you need but still allow explicit format strings.

[benrobster]

Looks good. Sorry I didn't reply to your original comments a few days ago, things have been crazy! You're probably right that the output format is the same either way. But I figure its Serializers' job to get raw python types, and Renderers job to convert serializer output to string formats, so this new approach can remain consistent with that, while allowing for customizing the output as well, optionally. I'm actually using the serializer output layer on its own for a few things (caching, using as template context) without sending them through renderers. This allows me to have my cake and eat it to: I can have an API, but can also use traditional view/template paradigm when I want it, getting the data composed and structured by the same serializers as the API, ensuring consistency. Anyhow, the fix looks great--allows the new features to come in, without disrupting the potential benefits of the former output. THANKS!

[tomchristie]

Closed by 2.2.5 release