Skip to content

Contradictory sentences in json docs #146061

Closed

Description

@jonathandung

Documentation

In the json docs, it is said that "the most compact representation" for json is used if None is passed as indent to json.dump (the default behaviour), under the json.dump "Parameters" section.

However, under the description for the separators parameter, this is said: "If [separators is ]None (the default), separators defaults to (', ', ': ') if indent is None, and (',', ': ') otherwise. For the most compact JSON, specify (',', ':') to eliminate whitespace." The claim that the default behaviour gives "the most compact representation" is thus wrong; separators=(',', ':') is actually required as well.

Section concerned (source):

   :param indent:
      If a positive integer or string, JSON array elements and
      object members will be pretty-printed with that indent level.
      A positive integer indents that many spaces per level;
      a string (such as ``"\t"``) is used to indent each level.
      If zero, negative, or ``""`` (the empty string),
      only newlines are inserted.
      If ``None`` (the default), the most compact representation is used.
   :type indent: int | str | None

   :param separators:
      A two-tuple: ``(item_separator, key_separator)``.
      If ``None`` (the default), *separators* defaults to
      ``(', ', ': ')`` if *indent* is ``None``,
      and ``(',', ': ')`` otherwise.
      For the most compact JSON,
      specify ``(',', ':')`` to eliminate whitespace.
   :type separators: tuple | None

I can open a PR if required.

Linked PRs

Activity

  1. added
    stdlibStandard Library Python modules in the Lib/ directory
    on Mar 17, 2026
  2. eendebakpt commented on Mar 17, 2026

    @eendebakpt
    Contributor

    @jonathandung You are correct. Changing the docs to "a compact representation" or "the most compact indentation" would address the issue I think. Adding the exact representation used is also possible, but would perhaps be a bit verbose.

    If you can make a PR with a suggestion for improvement that would be great!

  3. added
    triagedThe issue has been accepted as valid by a triager.
    on Mar 17, 2026
  4. jonathandung commented on Mar 17, 2026

    @jonathandung
    ContributorAuthor

    Sure, I will open a PR that closes this issue later.

  5. added a commit that references this issue on Mar 17, 2026
    17a3337
  6. serhiy-storchaka commented on Mar 18, 2026

    @serhiy-storchaka
    Member

    Please check also the docstrings.

  7. jonathandung commented on Mar 19, 2026

    @jonathandung
    ContributorAuthor

    Please check also the docstrings.

    Good catch!

    In the json source, specifically the json.dump docstring:

        If ``indent`` is a non-negative integer, then JSON array elements and
        object members will be pretty-printed with that indent level. An indent
        level of 0 will only insert newlines. ``None`` is the most compact
        representation.
    
        If specified, ``separators`` should be an ``(item_separator,
        key_separator)`` tuple.  The default is ``(', ', ': ')`` if *indent* is
        ``None`` and ``(',', ': ')`` otherwise.  To get the most compact JSON
        representation, you should specify ``(',', ':')`` to eliminate
        whitespace.
    

    This is also wrong! It should be along the lines of

        If ``indent`` is a non-negative integer, then JSON array elements and
        object members will be pretty-printed with that indent level. An indent
        level of 0 will only insert newlines. ``None`` gives a compact
        representation; see below.
    
        If specified, ``separators`` should be an ``(item_separator,
        key_separator)`` tuple.  The default is ``(', ', ': ')`` if *indent* is
        ``None`` and ``(',', ': ')`` otherwise.  To get the most compact JSON
        representation, you should specify ``(',', ':')`` to eliminate
        whitespace.
    

    I will edit that file in my fork as well.

  8. jonathandung commented on Mar 19, 2026

    @jonathandung
    ContributorAuthor

    Please check also the docstrings.

    Done

  9. added a commit that references this issue on May 11, 2026
  10. added 3 commits that reference this issue on May 11, 2026
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

    docsDocumentation in the Doc dirstdlibStandard Library Python modules in the Lib/ directorytriagedThe issue has been accepted as valid by a triager.

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions