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/