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