On Thu, 8 Aug 2019 at 22:31, Richard Musil <risa2000x@gmail.com> wrote:
I have not asked for means to serialize invalid JSON objects. Yes, with the "raw" output, you can create invalid JSON, but it does not mean you have to.
True. But my point was simply that the json module appears to be designed in a way that protects against the possibility of ending up with invalid JSON, and than seems like a reasonable design principle. I'm not arguing that there should not ever be such a feature, just that in the absence of a need for it (see below), designing for safety seems like a good choice.
Let's take a look at it from a different POV and focus on the original problem. Imagine this situation, I have a JSON string with this value: ``` msg2 = '{"val": 1.0000000000000000000000000000000000000000000000000000000000001}' ``` This is perfectly valid JSON representation of the float. I can parse it with standard module with default float handling and get this: ``` json:orig = {"val": 1.0000000000000000000000000000000000000000000000000000000000001} json:pyth = {'val': 1.0} json:seri = {"val": 1.0} ``` i.e Python chooses to represent it as 1.0 (which I guess is the closest to the original value) and then serialize it as such into the output. But I can use `parse_float=decimal.Decimal` option of the standard module and get this (with the custom encoder encoding it into the string): ``` dson:orig = {"val": 1.0000000000000000000000000000000000000000000000000000000000001} dson:pyth = {'val': Decimal('1.0000000000000000000000000000000000000000000000000000000000001')} dson:seri = {"val": "1.0000000000000000000000000000000000000000000000000000000000001"} ``` There is nothing wrong with the float in the original JSON and there is nothing wrong with representing that float with decimal.Decimal type either.
OK, and so far there's nothing that I would describe as a "problem".
What is missing is just corresponding encoder support. I want to be able to serialize the Decimal object into its JSON float form, not into a string or some custom map.
OK, so you're saying that this is "the original problem". Fine, but my response would be that without a reasonable use case for this, it's just how the json module works, and not a "problem". It's only a problem if someone wants to do something specific, and can't. The only use case you have given for needing this capability is to produce identical output when round tripping from JSON to objects and back to JSON. But whenever people have pushed back on the validity of this requirement, you've said that's not the point. So OK, if it's not the point, where's your use case that makes the lack of the encoder support you're requesting a problem? Basically you can't have it both ways - either persuade people that your use case (identical output) is valid, or present a different use case. Paul