Just trying to get a bit of clarification here.

We really do need to be clear on teh goals in order to choose the best implementation.

> well, no -- we did not agree to that.

Then I misread your statement:

"I can't think of, and I don't think anyone else has come up with, any
examples other than Decimal that require this "raw" encoding."

I think after I posted that, it became clear that there was interest in being able to preserve the exact encoding in the original JSON -- if that's the case, then strings need to be covered as well.

> If your goal is tp support full precision of Decimal, than the way to do
> that is to support serialization of the Decimal type. And that would also
> allow serialization of any other (numeric) type into a valid JSON number.
> But it seems your goal is not to be able to serialize Decimal numbers with
> full precision, but rather, to be able perfectly preserve the original JSON

 My goal is, as already mentioned:

To extend JSON encoder to support custom type to serialize into "JSON real number" (changed "fractional" to "real" to be aligned to Python source internal comment).

This includes support for decimal.Decimal, if it is the custom type the user chooses. I do not understand why you write that supporting Decimal is not my goal.

I did't mean supporting Decimal wasn't a goal, but that it was not the only goal.

You have made it clear (from your examples) that you want not just "to support custom type to serialize into "JSON real number", which could be supported by supporting Decimal, but that you want to be able to "to support custom type to serialize into "JSON real number" while controlling *exactly* how that is done.

You may not have encountered any issues yet where getting dull decimal precision wouldn't work, and think you only need to support full precision of decimal numbers (and I say decimal, because that is built in to JSON), but as has been pointed out:

"1.234"  and  ".1234E+1"  and "1234E-3"

Are all equally valid JSON encodings for the same value.

So if you want to be able to round-trip JSON, or exactly match another encoder, then you need to be able to control exactly how your custom type (Or any type) is serialized into a "JSON real number".

And if you want to support exactly matching another encoder for all JSON, then you need to support customized encoding of strings, too.

Personally, I don't think that this control is a valid goal of the built in json module -- but maybe others think it is.

The other issue on the table is whether it's a goal of the json module to make it hard to create invalid JSON -- I think that would be nice, but others don't seem to think so.

A NOTE on that:

Maybe it would be good to have an optional "validate" flag for the encoder, that would validate the generated JSON. False be default, so it wouldn't effect performance if not used. And users could turn it on only in their test code if desired. I would advocate for something like this if we do give users more control over the encoding.

(though I suppose simply trying to decode the generated JSON in your tests may be good enough)



> My summary:
> I support full precision serialization of the Decimal type -- it would
> extend the json module to more fully support the JSON spec.

My proposal is compatible with this, it is just it doesn't restrict the support to Decimal only.

> I don't think the json module should aim to allow users to fully control
> exactly how a given item is serialized, though if it did, it would be nice
> if it did a validity check as well.

Allowing the custom serialization into JSON real number only can be checked rerelatively easily (as I tried to outline in my previous post).

> But I suggest the way forward is to separate out the goal:
> a) This is what I want to be able to do.
> from
> b) This is how I suggest that be achieved
> Because you need to know (a) in order to know how to do (b) , and because
> you should make sure the core devs support (a) in the first place.

I believe I have defined my goal. If you think it is lacking in some way, I would try to improve it, let me know how.

The reason why I mentioned the current implementation (and outlined a possible way to extend it) was to show that it should not be difficult to ensure the JSON validity, which, strictly speaking, will be needed regardless the custom type implementation (even if the custom type was restricted to Decimal).
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/2PRTXRRW3UBIYVW4IOLYLIJ6YWOTG2QZ/
Code of Conduct: http://python.org/psf/codeofconduct/

Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython