Bulletproof json.dump?

[Frank Millman]

On 2020-07-06 3:08 PM, Jon Ribbens via Python-list wrote:
> On 2020-07-06, Frank Millman <frank at chagford.com> wrote:
>> On 2020-07-06 2:06 PM, Jon Ribbens via Python-list wrote:
>>> While I agree entirely with your point, there is however perhaps room
>>> for a bit more helpfulness from the json module. There is no sensible
>>> reason I can think of that it refuses to serialize sets, for example.
>>> Going a bit further and, for example, automatically calling isoformat()
>>> on date/time/datetime objects would perhaps be a bit more controversial,
>>> but would frequently be useful, and there's no obvious downside that
>>> occurs to me.
>>
>> I may be missing something, but that would cause a downside for me.
>>
>> I store Python lists and dicts in a database by calling dumps() when
>> saving them to the database and loads() when retrieving them.
>>
>> If a date was 'dumped' using isoformat(), then on retrieval I would not
>> know whether it was originally a string, which must remain as is, or was
>> originally a date object, which must be converted back to a date object.
>>
>> There is no perfect answer, but my solution works fairly well. When
>> dumping, I use 'default=repr'. This means that dates get dumped as
>> 'datetime.date(2020, 7, 6)'. I look for that pattern on retrieval to
>> detect that it is actually a date object.
> 
> There is no difference whatsoever between matching on the repr output
> you show above and matching on ISO-8601 datetimes, except that at least
> ISO-8601 is an actual standard. So no, you haven't found a downside.
> 

I don't understand. As you say, ISO-8601 is a standard, so the original 
object could well have been a string in that format. So how do you 
distinguish between an object that started out as a string, and an 
object that started out as a date/datetime object?

Frank