Christopher Barker wrote:
Since we agreed that the only type which needs such a treatment is JSON fractional number, it should not be that hard to check if the custom type output is valid.
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." The way I misread it is that only "JSON real number" requires ..., since I consider Decimal just an implementation means to achieve the goal, not the goal itself. Now I see that Decimal support is your goal.
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.
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).