Skip to content

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

Open
@ericsnowcurrently

Description

@ericsnowcurrently

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

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

Footnotes

  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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    extension-modulesC modules in the Modules dirtype-featureA feature request or enhancement

    Projects

    Status

    No status

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions