I appreciate the responses though I feel like I stirred a completely different
topic than I wanted :).
I am aware of the limitations of the float binary representation, and
consequently also the Python handling of that matter, and I am perfectly fine
with it.
This was not the point of my post. The reason I gave the example was only its
authenticity, i.e. there _is_ apparently a JSON serializer, which prefers the
value ending with '3'. Just for the info, I run the simple test with the C++
lib, and indeed the values:
json j3 = "{\"val\": 0.6441726684570313}"_json;
json j2 = "{\"val\": 0.6441726684570312}"_json;
both serialize to:0.6441726684570313
so it is clearly the matter of choice. But as I, and others, said, it really
does not matter.
I also did not want to discuss the design decisions about having JSON
unreliable for the hash calculation. In my app, I know I am only dealing with
integers, floats and strings (and arrays and maps), all withing the range of a
standard binary representation (i.e. nothing fancy) and while I agree that in
general, there are many unclear "corner cases" in JSON, I decided that hashing
the (normalized) textual representation was best I could do.
If I had to devise some other representation (possibly binary) for that, I
would have to also implicate this particular representation to any other client
verifying the hash, while the textual representation is already available and
does not need any other conversion or re-representation.
Anyway, what I wanted to point out is that the standard (in a sense of being
standard Python implementation) JSON decoder can apparently handle floats of
arbitrary precision with simply `parse_float` flag, which even uses another
built-in type decimal.Decimal.
On the other hand, there is no such flag available on its encoder counterpart,
nor even the custom written encoder (for decimal.Decimal) can do that because
of how it is implemented. It strikes me, even on a very abstract level, as a
kind of asymmetry in the API.
I do not know if this problem really only impacts the float case (and therefore
`simplejson` has already thought it out well by simply adding an explicit
option for that for its encoder), or it may affect some other types (maybe big
integers), in which case, something like I suggested in my OP could be the
solution.
What do you think about that?
_______________________________________________
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/IXM6ZAYKNMBPLCM7AX34JRNZS3CTMAHA/
Code of Conduct: http://python.org/psf/codeofconduct/
