Currently, the behavior of pretty-print is is controlled by the parameter indent in json.dump:
-
indent=None: everything is rendered on a single line -
indentset: the entire structure is recursively expanded
That means that if we set indent, pretty-print will “unfold” all the structures in the json.
However, for deeply nested or repetitive small structures (e.g. short lists or argument arrays), fully expanding every level can reduce readability.
For example, we have a json that was pretty-printed.
{
"Command": "comment",
"Args": [
"text1",
"",
"",
"",
""
]
}
But in cases like this, keeping "Args" on a single line would often be more compact and readable:
{
"Command": "comment",
"Args": ["text1", "", "", "", ""]
}
This can be partially achieved by writing a custom JSONEncoder, but that requires reimplementing parts of the encoding logic and is not very convenient.
What’s more, from its name, “indent” appears to describe only the indentation width, but in practice it also implicitly enables pretty-printing. This makes it difficult to control pretty-print behavior more precisely, as there is no dedicated parameter for that.
Proposal
Maybe we can introduce an optional parameter max_pretty to limit pretty-print expansion depth.
(Oh the name max_pretty is just an example, maybe we can have better idea.)
for example:
# module json definition after change
def dump(...,
max_pretty=0, # default is 0
indent=None
...)
# example
json.dump(data, fp, max_pretty=1, indent=4)
Then the sutrcture whose depth smaller than max_pretty (in this example value is 1) will be “unfolded” by pretty-print, and those equals or bigger than max_pretty will not and will be in a line.
{
"Command": "comment",
"Args": ["text1", "", "", "", ""]
}
The key “Command” and “Args” are in root (frame 0), so they will be pretty-printed; but the content of “Args” is in frame 1, so it will keep normal.
That small change can enable us to control how pretty-print works, and indent will no longer control if pretty-print is enabled, only means the indent width just as its name, making things more elegant.
That’s my opinion. What do you think? Would such an option be considered within scope for the standard library?