[Python-ideas] Serialization of CSV vs. JSON

[Wes Turner]

jsondate, for example, supports both .load[s]() and .dump[s](); but only
for UTC datetimes

https://github.com/rconradharris/jsondate/blob/master/jsondate/__init__.py

UTC is only sometimes a fair assumption; otherwise it's dangerous to assume
that timezone-naieve [ISO8601] strings represent UTC-0 datetimes. In that
respect - aside from readability - arbitrary-precision POSIX timestamps are
less error-prone.



On Saturday, November 3, 2018, David Shawley <daveshawley at gmail.com> wrote:

> On Nov 3, 2018, at 9:29 AM, Chris Angelico <rosuav at gmail.com> wrote:
>
>
> I think we need to clarify an important distinction here. JSON, as a
> format, does *not* support date/time objects in any way. But
> JavaScript's JSON.stringify() function is happy to accept them, and
> will represent them as strings.
>
>
> Very good point.  The JSON document type only supports object literals,
> numbers, strings, and Boolean literals.  My suggestion was specifically to
> provide an extensible mechanism for encoding arbitrary objects into the
> supported primitives.
>
> If the suggestion here is to have json.dumps(datetime.date(2018,11,4))
> to return an encoded string, either by natively supporting it, or by
> having a protocol which the date object implements, that's fine and
> reasonable; but json.loads(s) won't return that date object. So, yes,
> it would be asymmetric. I personally don't have a problem with this
> (though I also don't have any strong use-cases). Custom encoders and
> decoders could do this, with or without symmetry. What would it be
> like to add a couple to the json module that can handle these extra
> types?
>
>
> Completely agreed here.  I've seen many attempts to support "round trip"
> encode/decode in JSON libraries and it really doesn't work well unless you
> go
> down the path of type hinting.  I believe that MongoDB uses something akin
> to
> hinting when it handles dates.  Something like the following representation
> if I recall correctly.
>
> {
>     "now": {
>         "$type": "JSONDate",
>         "value": "2018-11-03T09:52:20-0400"
>     }
> }
>
> During deserialization they recognize the hint and instantiate the object
> instead of parsing it.  This is interesting but pretty awful for
> interoperability since there isn't a standard that I'm aware of.  I'm
> certainly not proposing that but I did want to mention it for completeness.
>
> I'll try to put together a PR/branch that adds protocol support in JSON
> encoder
> and to datetime, date, and uuid as well.  It will give us something to
> point at
> and discuss.
>
> - cheers, dave.
> --
> Mathematics provides a framework for dealing precisely with notions of
> "what is".
> Computation provides a framework for dealing precisely with notions of
> "how to".
> SICP Preface
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20181103/d7bf411e/attachment.html>