Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specific praise for the C API #30

Open
iritkatriel opened this issue May 15, 2023 · 2 comments
Open

Specific praise for the C API #30

iritkatriel opened this issue May 15, 2023 · 2 comments

Comments

@iritkatriel
Copy link
Member

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?

@gvanrossum
Copy link

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.

@steve-s
Copy link
Contributor

steve-s commented May 23, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants