路线图

本页面概述了 pandas 开发中的主要主题。每个主题都需要大量的努力才能实现。这些主题可以通过专门的资金或贡献者的兴趣更快地实现。

路线图上的项目并不意味着它一定会发生，即使有无限的资金。在实施期间，我们可能会发现阻止采用该功能的问题。

此外，路线图上没有的项目并不排除它被包含在 pandas 中。路线图旨在针对项目中可能需要数月或数年开发人员时间才能完成的较大、根本性更改。范围较小的项目将继续在我们 问题跟踪器 上进行跟踪。

路线图定义为一组名为 PDEPs 的主要增强提案。有关 PDEPs 以及如何提交 PDEPs 的更多信息，请参阅 PEDP-1。

PDEPs

正在讨论中

已接受

已实现

已拒绝

待定 PDEP 的路线图要点

可扩展性

Pandas 的 `extending.extension-types` 允许使用自定义数据类型和数组存储来扩展 NumPy 类型。Pandas 在内部使用扩展类型，并提供了一个接口供第三方库定义自己的自定义数据类型。

Pandas 的许多部分仍然无意中将数据转换为 NumPy 数组。这些问题对于嵌套数据尤其突出。

我们希望改进整个库中扩展数组的处理方式，使其行为与 NumPy 数组的处理方式更加一致。我们将通过清理 pandas 的内部结构并向扩展数组接口添加新方法来实现这一点。

字符串数据类型

目前，pandas 将文本数据存储在 `object` -dtype NumPy 数组中。当前实现有两个主要缺点：首先，`object` -dtype 不特定于字符串：任何 Python 对象都可以存储在 `object` -dtype 数组中，而不仅仅是字符串。其次：这效率不高。NumPy 内存模型不太适合可变宽度文本数据。

为了解决第一个问题，我们建议为字符串数据使用新的扩展类型。这将最初是选择加入的，用户明确请求 `dtype="string"`。支持此字符串类型的数组最初可能是当前实现：Python 字符串的 `object` -dtype NumPy 数组。

为了解决第二个问题（性能），我们将探索替代的内存中数组库（例如 Apache Arrow）。作为工作的一部分，我们可能需要实现 pandas 用户期望的某些操作（例如，`Series.str.upper` 中使用的算法）。这项工作可能在 pandas 之外完成。

Apache Arrow 互操作性

Apache Arrow 是一个用于内存中数据的跨语言开发平台。Arrow 逻辑类型与典型的 pandas 使用案例密切相关。

我们希望在 pandas 中提供对 Arrow 内存和数据类型的更好集成支持。这将使我们能够利用其 I/O 功能，并为使用 Arrow 的其他语言和库提供更好的互操作性。

索引和内部结构的解耦

获取和设置 pandas 数据结构中值的代码需要重构。特别是，我们必须清楚地将将键（例如，`DataFrame.loc` 的参数）转换为位置的代码与使用这些位置来获取或设置值的代码分开。这与提议的 BlockManager 重写有关。目前，BlockManager 有时使用基于标签的索引，而不是基于位置的索引。我们建议它应该只使用基于位置的索引，而键到位置的转换应该完全在更高层完成。

索引是一个复杂的 API，包含许多细微之处。此重构需要谨慎和关注。以下原则应启发索引代码的重构，并最终产生更简洁、更简单、更高效的代码。

  1. 标签索引绝不应在同一个轴上两次查找相同的标签。这意味着任何验证步骤都必须

  2. 将验证限制为一般特征（例如键/索引的 dtype/结构），或者

  3. 重用结果进行实际索引。

  4. 索引器绝不应依赖对其他索引器的显式调用。例如，.loc 的某些内部方法可以调用 __getitem__（或它们的公共基类）的某些内部方法，但在 .loc 的代码流中，绝不应该出现 the_obj[something]。

  5. 位置索引的执行绝不应涉及标签（如目前不幸发生的那样）。也就是说，对 .iloc 的 getter 调用（或右侧未索引的 setter 调用）的代码流绝不应以任何方式涉及对象的轴。

  6. 索引绝不应涉及访问/修改值（即，作用于 ._data 或 .values）超过一次。因此，以下步骤必须明确分离

  7. 找到我们需要在每个轴上访问/修改的位置

  8. （如果我们正在访问）推导出我们需要返回的对象类型（维度）
  9. 实际访问/修改值

  10. （如果我们正在访问）构造返回对象

  11. 作为 4.i 和 4.iii 之间分离的推论，任何处理数据存储方式的代码（包括处理多种 dtype 和稀疏存储、分类、第三方类型的任何组合）都必须独立于处理识别受影响行/列的代码，并且仅在步骤 4.i 完成后才进行。

  12. 特别是，此类代码很可能不应该放在 pandas/core/indexing.py 中

  13. ... 并且绝不应以任何方式依赖于轴的类型（例如，没有 MultiIndex 特殊情况）

  14. 作为点 1.i 的推论，Index（子）类必须为任何所需的标签有效性检查（不涉及实际查找）提供单独的方法，一方面，以及为任何所需的标签转换/调整/查找提供单独的方法，另一方面。

  15. 试错的使用应该有限，并且无论如何都应该限制为仅捕获实际预期的异常（通常为 KeyError）。

  16. 特别是，代码绝不应（有意地）在 try... exception 的 except 部分中引发新的异常。

  17. 任何不特定于设置器和获取器的代码部分都必须共享，当预期行为存在细微差异时（例如，使用.loc获取会因缺少标签而引发异常，而设置仍然不会），可以通过特定参数进行管理。

Numba 加速操作

Numba 是一个用于 Python 代码的 JIT 编译器。我们希望为用户提供方法，让他们能够在 pandas 接受用户定义函数的地方（例如，Series.apply、DataFrame.apply、DataFrame.applymap 以及在分组和窗口上下文中）应用自己的 Numba 加速函数。这将通过保持在编译代码内来提高这些操作中用户定义函数的性能。

文档改进

我们希望改进 pandas 文档的内容、结构和呈现方式。一些具体目标包括

性能监控

Pandas 使用 airspeed velocity 来监控性能回归。ASV 本身是一个很棒的工具，但需要一些额外的努力才能集成到开源项目的流程中。

asv-runner 组织目前由 pandas 维护者组成，提供基于 ASV 构建的工具。我们有一台物理机器用于运行多个项目的基准测试，以及管理基准测试运行和报告结果的工具。

我们希望为这些工具的改进和维护提供资金，以