Re: [Python-ideas] Serialization of CSV vs. JSON
On Nov 4, 2018, at 12:43 PM, Michael Selik <michael.selik@gmail.com> wrote:
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. - cheers, dave. [1]: https://github.com/dave-shawley/cpython/pull/2 <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
On 11/6/2018 6:46 AM, David Shawley wrote:
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
On 11/6/2018 6:46 AM, David Shawley wrote:
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
participants (2)
-
David Shawley -
Eric V. Smith