On Thu, 8 Aug 2019 at 22:31, Richard Musil <risa20...@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
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/KNMM55HTFTEMOUFJU5DB26VCVFBFKURZ/
Code of Conduct: http://python.org/psf/codeofconduct/
