You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue is to collect feedback on what's good about the C API.
Which aspects of the C API are good and should be preserved in the future?
Are there any particularly clever design choices or innovations you think are work mentioning?
The text was updated successfully, but these errors were encountered:
It's very convenient that for many APIs where one routinely needs to pass a string literal (e.g. PyObject_GetAttr), there's a version taking a C string literal (in this case, PyObject_GetAttrString). Compare this to the hassle if one had to construct a Unicode object from a C string literal to pass to PyObject_GetAttr.
Regarding Limited API and stable ABI compared to the full C API:
It hides at least some implementation details and memory layout of most of the runtime objects, which makes it simpler (but still hard) to implement on alternative Python implementations. However, alternative implementations usually still require recompilation from sources.
For the same reasons, it would be simpler for CPython to evolve its internals if only Limited API needed to be supported.
It does provide ABI stability. Why it is not used more in practice is another question.
Following up on #4 (comment):
This issue is to collect feedback on what's good about the C API.
Which aspects of the C API are good and should be preserved in the future?
Are there any particularly clever design choices or innovations you think are work mentioning?
The text was updated successfully, but these errors were encountered: