路线图
本页面概述了 pandas 开发中的主要主题。这些项目中的每一个都需要相对大量的精力来实现。如果能获得专门的资金或贡献者的兴趣,这些项目可能会更快实现。
路线图上的项目并不意味着它必然会发生,即使有无限的资金也是如此。在实现过程中,我们可能会发现阻止该功能采用的问题。
此外,未列入路线图的项目并不表示不会被纳入 pandas。路线图旨在涵盖那些对项目进行重大、基础性更改的项目,这些更改可能需要开发者花费数月甚至数年的时间。范围较小的项目将继续在我们的问题跟踪器上进行跟踪。
路线图由一系列名为 PDEP 的重大增强提案定义。有关 PDEPs 的更多信息以及如何提交,请参阅PEDP-1。
PDEPs
讨论中
已接受
- PDEP-1: 目的与指南
- PDEP-10: 将 PyArrow 作为默认字符串推断实现的必需依赖项
- PDEP-14: pandas 3.0 的专用字符串数据类型
- PDEP-17: 向后兼容性与废弃策略
已实现
- PDEP-4: 一致的日期时间解析
- PDEP-6: 在类似 setitem 的操作中禁止类型向上转换
- PDEP-7: 通过写时复制 (Copy-on-Write) 实现 pandas 中一致的复制/视图语义
已驳回
尚待 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,包含许多微妙之处。这次重构需要小心谨慎。以下原则应指导索引代码的重构,并应产生更清晰、更简单、性能更好的代码。
-
标签索引不得涉及在同一个轴上多次查找同一个标签。这意味着任何验证步骤必须要么
-
将验证限制在通用特征(例如,键/索引的 dtype/结构)上,或者
-
重用实际索引的结果。
-
索引器不得依赖对其他索引器的显式调用。例如,
.loc
的某个内部方法调用__getitem__
(或它们的公共基类)的某个内部方法是可以的,但在.loc
的代码流中绝不应出现the_obj[something]
。 -
位置索引的执行绝不能涉及标签(遗憾的是,目前情况如此)。也就是说,getter 调用(或右侧未被索引的 setter 调用)到
.iloc
的代码流绝不应以任何方式涉及对象的轴。 -
索引绝不能涉及多次访问/修改值(即,操作
._data
或.values
)。因此,以下步骤必须明确解耦: -
找到我们需要在每个轴上访问/修改的位置
- (如果我们正在访问)推导我们需要返回的对象类型(维度)
- 实际访问/修改值
-
(如果我们正在访问)构造返回对象
-
作为 4.i 和 4.iii 之间解耦的推论,任何处理数据存储方式的代码(包括处理多种 dtype、稀疏存储、分类类型、第三方类型的任何组合)必须独立于处理识别受影响行/列的代码,并且仅在步骤 4.i 完成后发生。
-
特别是,此类代码很可能不应该存在于
pandas/core/indexing.py
中 -
... 并且绝不能以任何方式依赖于轴的类型(例如,没有
MultiIndex
特殊情况) -
作为点 1.i 的推论,
Index
(子)类必须提供单独的方法,一方面用于对标签进行所需的有效性检查而不涉及实际查找,另一方面用于对标签进行任何所需的转换/适配/查找。 -
试错的使用应受到限制,无论如何应仅限于捕获实际预期的异常(通常是
KeyError
)。 -
特别是,代码绝不应在
try... exception
的except
部分(有意地)引发新的异常 -
任何不特定于 setter 和 getter 的代码部分都必须共享,当预期行为有微小差异时(例如,使用
.loc
获取时对缺失标签会引发错误,而设置时则不会),可以通过特定参数进行管理。
Numba 加速操作
Numba 是一个用于 Python 代码的 JIT 编译器。我们希望提供方法,让用户在 pandas 接受用户定义函数的地方(例如,Series.apply
、DataFrame.apply
、DataFrame.applymap
,以及分组和窗口上下文)应用他们自己的 Numba JIT 编译函数。这将通过保持在编译代码中来提高这些操作中用户定义函数的性能。
文档改进
我们希望改进 pandas 文档的内容、结构和呈现方式。一些具体目标包括:
- 使用现代化、响应式设计彻底改进 HTML 主题 (
15556
) - 改进“入门”文档,为不同背景的用户(例如,编程新手、熟悉 R 等其他语言的用户、已熟悉 Python 的用户)设计和编写学习路径。
- 改进文档的整体组织以及文档的特定子部分,以便更容易导航和查找内容。
性能监控
Pandas 使用airspeed velocity来监控性能退步。ASV 本身是一个很棒的工具,但需要一些额外的工作才能集成到开源项目的工作流程中。
asv-runner 组织目前由 pandas 维护者组成,提供基于 ASV 构建的工具。我们有一台物理机用于运行多个项目的性能基准测试,以及管理基准测试运行和报告结果的工具。
我们希望资助这些工具的改进和维护,以便:
- 更稳定。目前,它们是在维护者有空闲时间时在晚上和周末维护的。
- 根据https://pyperf.readthedocs.io/en/latest/system.html调整系统以进行性能基准测试,提高稳定性。
- 构建一个 GitHub 机器人,在合并 PR 之前请求运行 ASV。目前,性能基准测试仅每晚运行。