Skip to content

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

Closed as not planned

Description

@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?

Activity

  1. lelit commented on Oct 26, 2023

    @lelit
    Contributor

    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?

  2. jamesbraza commented on Oct 26, 2023

    @jamesbraza
    Author

    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)
  3. lelit commented on Oct 26, 2023

    @lelit
    Contributor

    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.

  4. jamesbraza commented on Oct 26, 2023

    @jamesbraza
    Author

    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

  5. jamesbraza commented on Oct 26, 2023

    @jamesbraza
    Author

    Thanks again, appreciated btw!

  6. lelit commented on Oct 26, 2023

    @lelit
    Contributor

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

  7. lelit commented on Oct 26, 2023

    @lelit
    Contributor

    FTR, commit 8b5fe38 fixes the issue with write_mode.

  8. lelit commented on Oct 26, 2023

    @lelit
    Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions