python / python/cpython

Modern defaults for `pprint`

未关闭
#149,189 12 条评论 11 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

stdlib type-feature
主要语言
Python
星标
77.2k
派生
35.9k
PR 合并指标
PR 指标待抓取

描述

Feature or enhancement

Proposal:

Python 3.15 introduces the expand keyword for pprint, which improves the output:

  • expand (bool) – If True, opening parentheses and brackets will be followed by
    a newline and the following content will be indented by one level, similar to
    pretty-printed JSON. Incompatible with compact.

For example, this code:

from pprint import pprint

config = {
    "database": {
        "host": "db.example.com",
        "port": 5432,
        "options": {
            "connect_timeout": 5,
            "pool_size": 10,
            "ssl": True,
            "sslmode": "verify-full",
        },
    },
    "logging": {
        "level": "INFO",
        "file": "/var/log/app.log",
        "handlers": {
            "console": {"enabled": True},
            "file": {"rotate": True, "max_bytes": 1048576},
        },
    },
}

print("===== expand=False =====")
print()
pprint(config)

print()

print("===== expand=True =====")
print()
pprint(config, expand=True)

Produces:

===== expand=False =====

{'database': {'host': 'db.example.com',
              'options': {'connect_timeout': 5,
                          'pool_size': 10,
                          'ssl': True,
                          'sslmode': 'verify-full'},
              'port': 5432},
 'logging': {'file': '/var/log/app.log',
             'handlers': {'console': {'enabled': True},
                          'file': {'max_bytes': 1048576, 'rotate': True}},
             'level': 'INFO'}}

===== expand=True =====

{
 'database': {
  'host': 'db.example.com',
  'options': {
   'connect_timeout': 5,
   'pool_size': 10,
   'ssl': True,
   'sslmode': 'verify-full',
  },
  'port': 5432,
 },
 'logging': {
  'file': '/var/log/app.log',
  'handlers': {
   'console': {'enabled': True},
   'file': {'max_bytes': 1048576, 'rotate': True},
  },
  'level': 'INFO',
 },
}

"Prettiness" is subjective, but in my opinion, the expanded output looks nicer and is much easier to read. It's also closer to code formatted with modern tools like Black and Ruff.

Opinions about pprint

Others also don't like the current default:

For a long time I was unhappy with default values that standard pprint module has
(from pprint import pprint). So, I decided to change them as I like and not pass
them every call to pprint.

https://alex-ber.medium.com/my-pprint-module-f25a7b695e5f

However, it has a very greedy layout algorithm that fails to produce pretty output in
many cases.

https://tommikaikkonen.github.io/introducing-prettyprinter-for-python/

pprint++: a drop-in replacement for pprint that's actually pretty ... Why is it
prettier? Unlike pprint, `pprint++ strives to emit a readable, largely
PEP8-compliant, representation of its input.

https://github.com/wolever/pprintpp

the current output for a large nested dictionary with pprint is basically unusable and
definitely not pretty, which is a shame because large dictionaries are probably the
primary use case for pprint.

https://github.com/python/cpython/issues/112632#issuecomment-2597056481

When working with deeply nested dictionaries (depth 4+), readability becomes critical.
Python’s built-in `pprint module is the default choice for "pretty printing," but it
often falls short with deep nesting—producing cluttered, inconsistently indented
output that’s hard to parse.

https://www.pythontutorials.net/blog/how-to-pretty-print-nested-dictionaries/

I don't really fancy the way Python's pprint formats the output. [...] But I'd like it
to be [...] in the style of Black

https://stackoverflow.com/questions/69945869/pretty-printing-python-dictionary-lists-in-black-style

Other tools and workarounds

The formatting can be improved by using third-party libraries, for example, rich.print(), and pprintpp and alexber.utils.pprint mentioned above. Or by changing the defaults yourself, or following an oft-recommended and somewhat roundabout print(json.dumps(d, indent=4)).

But pprint is often used for debugging because it's always within arm's reach: you just want to import pprint as pprint and pprint(my_var).

Therefore, I believe it would be beneficial to modernise pprint's defaults:

argument before after
expand False True
indent 1 4
width 80 88

pp()

pp() was added to 3.8 in 2017. It's the same as pprint() but with sort_dicts=False.

This is from the discussion preceding its addition, which considered changing the pprint() default:

I guess the underlying issue here is partly the question of what the pprint module
is for. In my understanding, it's primarily a tool for debugging/introspecting
Python programs, and the reason it talks about "valid input to the interpreter"
isn't because we want anyone to actually feed the data back into the interpreter,
but to emphasize that it provides an accurate what-you-see-is-what's-really-there
view into how the interpreter understands a given object. It also emphasizes that
this is not intended for display to end users; making the output format be "Python
code" suggests that the main intended audience is people who know how to read, well,
Python code, and therefore can be expected to care about Python's semantics.

pprint.pprint() is indeed mostly for debugging, but not always. As an example of what
will break if you change the sorting guarantee: in Mailman 3 the REST etag is
calculated from the pprint.pformat() of the result dictionary before it’s JSON-ified.
If the order is changed, then it’s possible a client will have an incorrect etag for a
structure that is effectively the same.

https://mail.python.org/archives/list/python-dev@python.org/message/UYMINUYHZ3O7B2DKXI7B2T42TYCJFZ3N/
https://mail.python.org/pipermail/python-dev/2017-December/151403.html

I agree changing sort_dicts changes the code output.

But display output is different and is safer to change: parsing the output will get you the same thing. As long as you're not doing brittle character-level parsing, it's essentially the same Python code.

Alternatives

I'm also open to:

  • Only change defaults for pp (similar to this suggestion)
  • Add a new function with these defaults, somewhat similar to pp
  • Perhaps a new keyword to define a new style, that would override these defaults
Has this already been discussed elsewhere?

No response given

Links to previous discussion of this feature:

No response

Linked PRs
  • gh-149190
  • gh-150249
  • gh-150268

贡献指南

打开贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

调研方向

先阅读 pprint.pprint() 和 pprint.pp() 入口,以及提案中 expand、indent 和 width 的默认值。在决定哪种 API 或默认值变更可以接受之前,检查相关的 pull request 和现有的 pprint 行为。确定一条经过一致同意且配有兼容测试和文档的现代化路径后,即视为完成。

由索引模型根据 Issue 内容生成。

评估

技术栈
python
领域
tooling
Issue 类型
功能
难度
5/5
预计耗时
一周以上
活跃度
停滞
描述清晰度
基本清楚
新手友好度
25/100

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。