dumps with WM_PRETTY not indented by 4 spaces when keys are int

[jamesbraza]

With python-rapidjson==1.12:

import rapidjson

data = {1: "hi"}
rapidjson.dumps(str(data), write_mode=rapidjson.WM_PRETTY)

I expect it to print:

{
    1: "hi"
}

However, it prints:

"{1: \'hi\'}"

Is this a bug, or is this just expected behavior when keys are int?

[lelit]

Assuming the "however, it prints" comes from something else: you are passing a str, and that will be emitted as such, surely not at a prettified dictionary.
Why are you expecting that?

[jamesbraza]

HA my bad, I pasted in the wrong thing, editing my OP 😅.

I guess my expectation comes from https://python-rapidjson.readthedocs.io/en/latest/dumps.html's section on WM_PRETTY printing with an indent of 4 spaces.

Basically I am trying to pretty print a blob with int keys. I am:

• Thinking because this blob isn't valid JSON, it explains why 4-space indents aren't happening
• Wondering though if 4-space indents should still be appearing (hence this issue)

[lelit]

I'm sorry, but I'm afraid that cannot work, the underlying rapidjson library adheres to standard JSON (with just a few exceptions), and a JSON object requires string keys. As said, if you pass a string to dumps(), there is no way that it will discover that it contains an (invalid) JSON representation, parse it and redump the result as a pretty formatted JSON.

[jamesbraza]

Yeah I was also experimenting with this:

rapidjson.dumps(data, default=str, write_mode=rapidjson.WM_PRETTY)

Unfortunately, it gives the same results. Thanks for confirming my intuitions here, going to close this out

[jamesbraza]

Thanks again, appreciated btw!

[lelit]

It turns out that something is wrong with write_mode...

[lelit]

FTR, commit 8b5fe38 fixes the issue with write_mode.

[lelit]

Sigh, that commit references the wrong issue 😶‍🌫️