search

capi-workgroup / problems

Discussions about problems with the current C Api
19 stars 6 forks source link

Exported data (`PyAPI_DATA` rather than `PyAPI_FUNC`) #80

Open encukou opened 1 month ago

encukou commented 1 month ago

Exporting data from shared libraries is problematic, and we should instead export functions that fetch the data. This issue didn't make it to PEP 733 (aside from a passing reference to “non-function symbols”).

I don't recall the reason behind this, and I'd like to have it written down so we avoid cargo-culting. @zooba, could you fill it in here? (Or in the guidelines draft?)

steve-s commented 1 month ago

In HPy we also chose to avoid exporting data, the reason is that function call is more flexible (can be switched to lazy initialization or on demand computation, for example). On top of that I am not sure how well are exported data and (re-)exporting data supported in non-C languages.

zooba commented 1 month ago

Yeah, @steve-s has basically nailed it. My proposed text (but feel free to rewrite/amend):

Data exports (``PyAPI_DATA``) should no longer be used to make global variables
available to embedders and extensions. Instead, use a function (``PyAPI_FUNC``)
that returns the value and an error code (which may just be a ``NULL`` return).
Any allocation, copying, or reference counting should be performed within the
function. This protects against future changes, such as to thread safety or
refcounting, allows the addition of deprecation warnings or failure conditions,
and better supports non-C callers.

The C API Working Group may approve exceptions to any of these guidelines.