路线图

本页面概述了 pandas 开发中的主要主题。这些项目中的每一个都需要相对大量的精力来实现。如果能获得专门的资金或贡献者的兴趣，这些项目可能会更快实现。

路线图上的项目并不意味着它必然会发生，即使有无限的资金也是如此。在实现过程中，我们可能会发现阻止该功能采用的问题。

此外，未列入路线图的项目并不表示不会被纳入 pandas。路线图旨在涵盖那些对项目进行重大、基础性更改的项目，这些更改可能需要开发者花费数月甚至数年的时间。范围较小的项目将继续在我们的问题跟踪器上进行跟踪。

路线图由一系列名为 PDEP 的重大增强提案定义。有关 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"。支持此字符串 dtype 的数组最初可能是当前的实现：一个由 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. 位置索引的执行绝不能涉及标签（遗憾的是，目前情况如此）。也就是说，getter 调用（或右侧未被索引的 setter 调用）到 .iloc 的代码流绝不应以任何方式涉及对象的轴。

  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. 任何不特定于 setter 和 getter 的代码部分都必须共享，当预期行为有微小差异时（例如，使用 .loc 获取时对缺失标签会引发错误，而设置时则不会），可以通过特定参数进行管理。

Numba 加速操作

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

文档改进

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

性能监控

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

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

我们希望资助这些工具的改进和维护，以便：