[Python-ideas] Serialization of CSV vs. JSON

[Eric V. Smith]

On 11/6/2018 6:46 AM, David Shawley wrote:
> On Nov 4, 2018, at 12:43 PM, Michael Selik <michael.selik at gmail.com 
> <mailto:michael.selik at gmail.com>> wrote:
> > If you're making a module
> >>
> > > On Sun, Nov 4, 2018, 5:49 AM David Shawley <daveshawley at gmail.com 
> <mailto:daveshawley at gmail.com> wrote:
> > > Personally, I would place this sort of serialization logic outside 
> of the
> > > Standard Library -- maybe following the pattern that the rust 
> community
> > > adopted on this very issue.  In short, they separated serialization &
> > > de-serialization into a free-standing library.
> >
> > You don't need a bug on the tracker or discussion on -dev to share a 
> module
> > on PyPI or GitHub. When you've got something started, share a link 
> in this
> > thread.
>
> I modified a branch of python/cpython to implement what I had in mind. [1]
> The idea is to introduce a new protocol with a single method:
>
>     self.jsonformat() -> object
>
>     If this method exists, then json.encoder.JSONEncoder will call it
>     to generate a JSON representation *instead* of calling *default*.
>     This method must return a value that json.encoder.JSONEncoder can
>     encoder or fail in the same manner as the *default* hook.
>
> The implementation wasn't too difficult once I learned a little more about
> how Standard Library classes are implemented when C speedups are included.
> There are a few things that I haven't done:
>
> 1. I didn't guard the functionality with a flag to the JSONEncoder
>    initializer.  This was oversight but I would add one before doing a PR
>    against python/cpython.
>
> 2. As discussed before this is an asymmetric proposal since there is no
>    support for detecting and de-serializing in JSONDecoder.
>
> That is what I had in mind.  I'm not sure how we want to spell extension
> methods like this one.  I chose to not use a double-underscore method 
> since
> I view them as ``for use by the interpreter/language'' more so than for
> Library-recognised methods.  The name is the least of my worries.
>
> Let me know if there is any reason that I shouldn't move forward with 
> a bpo
> and PR against python/cpython.
>

I wouldn't support putting this in the stdlib yet. We need to get 
real-world experience first. Modifying existing object with what's 
basically a new protocol seems too heavyweight for a protocol that's not 
all that commonly used.

How about implementing this with functools.singledispatch? It's designed 
for exactly this sort of case: some base functionality, then per-type 
specialization. It would be super-easy to whip up something with 
datetime.date and datetime.datetime specializations. I have a long-term 
goal of moving parts of the stdlib to singledispatch where it makes 
sense (say the next generation of pprint, for example).

I also think you should pass in a context object, and maybe have None 
signify a default context, although I'll admit I haven't thought it 
through yet. It will take some design iterations to get it right, once 
the use cases are clear.

Eric


> - cheers, dave.
>
> [1]: https://github.com/dave-shawley/cpython/pull/2
>
> --
> /"State and behavior. State and behavior. If it doesn’t bundle state 
> and behavior in a sensible way, it should not be an object, and there 
> should not be a class that produces it."/eevee
>
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct:http://python.org/psf/codeofconduct/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20181106/fa2a22ad/attachment-0001.html>