python / python/cpython

datetime: Stop Exposing Process-Global Objects in the datetime C-API

未关闭
#122,184 3 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

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

描述

Feature or enhancement

Proposal:

The datetime module has its own C-API which is enabled with PyDateTime_IMPORT. From the docs:

Before using any of these functions, the header file datetime.h must be included in your source
(note that this is not included by Python.h), and the macro PyDateTime_IMPORT must be invoked,
usually as part of the module initialisation function. The macro puts a pointer to a C structure into
a static variable, PyDateTimeAPI, that is used by the following macros.

My main concern is that the PyDateTimeAPI struct is a process-global value, but it exposes object pointers (which should always be per-interpreter). We have worked around this in 3.13+, but it would be better if we could make the objects per-interpreter.

FTR, here are the objects exposed directly by PyDateTimeAPI:

  • (static type) PyDateTime_DateType
  • (static type) PyDateTime_DateTimeType
  • (static type) PyDateTime_TimeType
  • (static type) PyDateTime_DeltaType
  • (static type) PyDateTime_TZInfoType
  • (singleton) utc_timezone (an instance of PyDateTime_TimeZoneType)

exposed indirectly:

  • (static type) PyDateTime_TimeZoneType

In order to make these objects per-interpreter, it would require changes to the datetime C-API. [^1] I expect we would leave PyDateTime_IMPORT alone. Instead, we'd need to update the macros in datetime.h to get the objects from the module associated with the current interpreter. [^2]

[^1]: These would be ABI-incompatible changes, which wouldn't be a problem unless the datetime C-API is part of the limited API).
[^2]: Anyone who is accessing the PyDateTimeAPI struct directly would have to change their code. It might make sense to provide a getter function/macro for each of the objects.

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

No response

贡献指南

打开贡献指南

从这里开始

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

调研方向

先从 datetime C-API 文档以及提案中描述的 datetime.h 宏开始,然后检查 PyDateTimeAPI 如何公开所列类型和 utc_timezone。完成的标准是这些对象按解释器隔离,而 PyDateTime_IMPORT 保持不变,并且任何所需的 getter 或直接访问更改都已记录并经过测试。

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

评估

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

把新 issue 发到你的邮箱

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