On Aug 8, 2019, at 13:29, Richard Musil firstname.lastname@example.org wrote:
I am not sure I have ever asked for bit-for-bit identical JSON representation.
Your complaint is that the hash is different. If you don’t get bit-for-bit identical JSON representation, the hash will not be the same. So either you _are_ asking for it, or you’re asking for something that won’t actually solve your problem (in which case, why do it?).
And I don’t know how output could be “raw” in an sense other than letting you specify the exact byte representation for it, so I don’t get what you’re saying when you claim you want the former but don’t want the latter.
I have always only mentioned `decimal.Decimal` and the lack of proper way to encode it (while having the proper way of decoding it), and if you read the subject of the OP it is asking for "raw output" (in the encoder, nothing about underlying representation)
If decimal really is the only case you or anyone else is ever going to care about, you shouldn’t be asking for “raw output”, you should either be asking for simplejson’s use_decimal to be brought into the stdlib, or just using simplejson in the first place.
If you really do need support for raw output, you’d need a new hook besides default, say, rawdefault. This wouldn’t be hard. Other than passing it up and down the chain of APIs, the only trick should be the C and Python code down in _iterencode that that do this:
o = _default(o) yield from _iterencode(o, _current_indent_level)
… with something like:
ro = _rawdefault(o) if r is not NotImplemented: yield ro else: o = _default(o) yield from _iterencode(o, _current_indent_level)
But I’m pretty sure simplejson had issues raised for something to generalize use_decimal this way and always rejected it.
However, that might be only because all such suggestions also had other problems. Often they either come along with “I want my hook called _before_ the normal encoding, rather than between normal encoding and default”, which has serious performance implications, or “I want to be able to create invalid JSON so it can be eval’d as JS code”, which is just a bad idea. This one doesn’t have either of those problems, and maybe it doesn’t have _any_ problems that have come up in the past, but someone has to go through the simplejson issues to figure that out.
So, if you really want this, come up with a use case that actually needs it, make sure you’ve answered whatever objections were raised in the past for simplejson if any, and ideally write a patch to simplejson and/or CPython (but if you can’t, I think this one is easy enough that you can hope someone else does), and you’ll probably get a difference response than you get by defensively claiming that you’re not asking for what you’re asking for but then repeating your need for it anyway.