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.
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.
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.
Which is exactly what happens with `simplejson` and `use_decimal=True` set:
```
sjson:orig = {"val":
1.0000000000000000000000000000000000000000000000000000000000001}
sjson:pyth = {'val':
Decimal('1.0000000000000000000000000000000000000000000000000000000000001')}
sjson:seri = {"val":
1.0000000000000000000000000000000000000000000000000000000000001}
```
And this is what is missing in the current implementation and there seems to be
different ways how to address it, as Angelo pointed out.
At the moment standard module basically does not allow creating a perfectly
valid JSON float which does not have valid binary representation, while at the
same time, allows decoding such a float (without a precision loss with the
decimal.Decimal). This is the asymmetry I am talking about. Why the output
should be limited by underlying implementation, while the input is not?
_______________________________________________
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/RX3XFJYREUVDI4ON5UHZHYGYINCC3TCR/
Code of Conduct: http://python.org/psf/codeofconduct/
