On Fri, 9 Aug 2019 at 15:20, Richard Musil <risa20...@gmail.com> wrote: > > JSON objects are specified by their textual representation (json.org). > Choosing some binary representation for them (so they can be processed > efficinetly) which does not preserve their value is the problem of the > underlying binary representation, not of the JSON format per se.
>From ECMA-404, linked from that page: The goal of this specification is only to define the syntax of valid JSON texts. Its intent is not to provide any semantics or interpretation of text conforming to that syntax. It also intentionally does not define how a valid JSON text might be internalized into the data structures of a programming language. There are many possible semantics that could be applied to the JSON syntax and many ways that a JSON text can be processed or mapped by a programming language. Meaningful interchange of information using JSON requires agreement among the involved parties on the specific semantics to be applied. Defining specific semantic interpretations of JSON is potentially a topic for other specifications So yes, how JSON is translated into language data structures is out of the scope of the JSON spec. So you're proposing a change to the Python language stdlib implementation of that translation. Fine. But you have yet to provide a justification for such a change, except the original background description, which you yourself have repeatedly claimed is irrelevant, of getting identical output from a JSON->internal->JSON round trip. So as far as I can see we're left with "please change the stdlib json module, because I think this behaviour would be better (oh, and incidentally it would solve an issue I have that's not relevant to my argument that the module should change)". > From the JSON point of view 0.6441726684570313 is perfectly valid float (or > better say _number_ as it is what JSON uses) and 0.6441726684570312 is > perfectly valid _and different_ number, because it differs in the last digit. Well, technically, JSON doesn't claim they are different, because it doesn't define comparison between its "number" objects... As you point out later in the same post, "3.0" and "3.0000" are different in the sense that you define, but how is that relevant or helpful? The JSON spec adds no semantics, so language bindings get to do what they want. So you're proposing a change to the Python language bindings. We get that. (At least I think most of us do by now). But I'm not sure you're getting the point that you need to justify your proposal, and you can't (by your own argument) do so by reference to the JSON spec, and you aren't (by your own admission) doing so based on round tripping. So what is your justification for wanting this change? "It makes more sense" doesn't seem to be getting much traction with people here. "Decimal offers better accuracy" also seems not to be very persuasive. 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/LUS2IPA4LTAELKGWY7RBTGXHTCST4KGP/ Code of Conduct: http://python.org/psf/codeofconduct/
