On Nov 4, 2018, at 12:43 PM, Michael Selik <michael.se...@gmail.com> wrote: > If you're making a module >> > > On Sun, Nov 4, 2018, 5:49 AM David Shawley <daveshaw...@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. - 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
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/