On Aug 8, 2019, at 13:29, Richard Musil <[email protected]> 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.
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/JLWSX5HTYNFYFYAKBTUICEGKYAZRKFLQ/
Code of Conduct: http://python.org/psf/codeofconduct/
