为文档贡献#

为文档贡献使所有使用 pandas 的人受益。我们鼓励您帮助我们改进文档，您不必是 pandas 专家！事实上，文档中有一些部分在专家撰写后变得更糟。如果文档中的某些内容对您来说没有意义，那么在您弄清楚后更新相关部分是一个很好的方法，以确保它能帮助下一个人。请访问 问题页面，查看有关 Pandas 文档当前开放的所有问题列表。

关于 pandas 文档#

文档是用 reStructuredText 编写的，它几乎就像用纯英语写作一样，并且使用 Sphinx 构建。Sphinx 文档有一个很棒的 reST 简介。查看 Sphinx 文档以对文档进行更复杂的更改。

关于文档的一些其他重要事项

  • pandas 文档由两部分组成：代码本身的文档字符串和此文件夹中的文档 doc/。

    文档字符串清楚地解释了各个函数的用法，而此文件夹中的文档包含每个主题的教程式概述以及其他一些信息（新增内容、安装等）。

  • 文档字符串遵循 pandas 约定，基于 Numpy 文档字符串标准。遵循 pandas 文档字符串指南 以获取有关如何编写正确文档字符串的详细说明。

  • 教程大量使用 IPython 指令 sphinx 扩展。此指令允许您在文档中放置将在文档构建期间运行的代码。例如

    .. ipython:: python

    x = 2
    x**3

    将呈现为

    In [1]: x = 2

In [2]: x**3
Out[2]: 8

    文档中的几乎所有代码示例都在文档构建期间运行（并保存输出）。这种方法意味着代码示例将始终保持最新，但它确实使文档构建变得更加复杂。

  • 我们的 API 文档文件位于 doc/source/reference 中，包含从 docstring 自动生成的文档。对于类，在控制哪些方法和属性自动生成页面方面有一些细微之处。

    我们有两个用于类的自动摘要模板。

    1. _templates/autosummary/class.rst。当您想要为类上的每个公共方法和属性自动生成页面时，请使用此模板。 Attributes 和 Methods 部分将由 numpydoc 自动添加到类的渲染文档中。请参阅 DataFrame 作为示例。

    2. _templates/autosummary/class_without_autosummary。当您想要选择要自动生成页面的方法/属性子集时，请使用此模板。使用此模板时，您应该在类 docstring 中包含一个 Attributes 和 Methods 部分。请参阅 CategoricalIndex 作为示例。

    每个方法都应该包含在 toctree 中，该 toctree 位于 doc/source/reference 中的某个文档文件中，否则 Sphinx 会发出警告。

实用脚本 scripts/validate_docstrings.py 可用于获取 API 文档的 csv 摘要。还可以验证特定类、函数或方法的文档字符串中的常见错误。该摘要还比较了 doc/source/reference 中文件中记录的方法列表（用于生成 API 参考 页面）和实际的公共方法。这将识别在 doc/source/reference 中记录但实际上不是类方法的方法，以及在 doc/source/reference 中未记录的现有方法。

更新 pandas 文档字符串#

在改进单个函数或方法的文档字符串时，不一定需要构建完整的文档（见下一节）。但是，有一个脚本可以检查文档字符串（例如，对于 DataFrame.mean 方法）。

python scripts/validate_docstrings.py pandas.DataFrame.mean

如果存在，此脚本将指示一些格式错误，并且还将运行和测试文档字符串中包含的示例。查看 pandas 文档字符串指南，了解有关如何格式化文档字符串的详细指南。

文档字符串中的示例（“doctests”）必须是有效的 Python 代码，以确定性方式返回所呈现的输出，并且用户可以复制和运行。可以使用上面的脚本检查这一点，并且在 Travis 上也进行了测试。失败的 doctest 将是合并 PR 的阻碍。查看 示例 文档字符串指南中的部分，了解一些使 doctests 通过的技巧和窍门。

在进行带有文档字符串更新的 PR 时，最好在 github 上的评论中发布验证脚本的输出。

如何构建 pandas 文档#

要求#

首先，您需要拥有一个开发环境才能构建 pandas（请参阅有关 创建开发环境 的文档）。

构建文档#

那么如何构建文档呢？在控制台中导航到本地 doc/ 目录并运行

python make.py html

然后你可以在文件夹 doc/build/html/ 中找到 HTML 输出。

第一次构建文档时，它会花费相当长的时间，因为它必须运行所有代码示例并构建所有生成的文档字符串页面。在随后的调用中，sphinx 将尝试只构建已修改的页面。

如果你想进行完整的清理构建，请执行

python make.py clean
python make.py html

你可以告诉 make.py 只编译文档的单个部分，从而大大减少检查更改的周转时间。

# omit autosummary and API section
python make.py clean
python make.py --no-api

# compile the docs with only a single section, relative to the "source" folder.
# For example, compiling only this guide (doc/source/development/contributing.rst)
python make.py clean
python make.py --single development/contributing.rst

# compile the reference docs for a single function
python make.py clean
python make.py --single pandas.DataFrame.join

# compile whatsnew and API section (to resolve links in the whatsnew)
python make.py clean
python make.py --whatsnew

相比之下，完整的文档构建可能需要 15 分钟，但单个部分可能只需要 15 秒。后续构建只会处理你更改的部分，因此会更快。

构建将自动使用你的机器上可用的核心数量来加快文档构建速度。你可以覆盖此

python make.py html --num-jobs 4

在 Web 浏览器中打开以下文件以查看你刚刚构建的完整文档 doc/build/html/index.html。

你将有幸看到你新改进的文档！

构建主分支文档#

当拉取请求合并到 pandas main 分支时，文档的主要部分也会由 Travis-CI 构建。这些文档随后托管在 这里，另请参阅 持续集成 部分。

预览更改#

提交拉取请求后，GitHub Actions 将自动构建文档。要查看已构建的站点

  1. 等待 CI / Web and docs 检查完成。

  2. 点击它旁边的 Details。

  3. 从 Artifacts 下拉菜单中，点击 docs 或 website 以将站点下载为 ZIP 文件。