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

Provide PyLong conversions with Py_(u)intptr_t #110863

Open
pitrou opened this issue Oct 14, 2023 · 4 comments
Open

Provide PyLong conversions with Py_(u)intptr_t #110863

pitrou opened this issue Oct 14, 2023 · 4 comments
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) topic-C-API type-feature A feature request or enhancement

Comments

@pitrou
Copy link
Member

pitrou commented Oct 14, 2023

Feature or enhancement

Proposal:

The following C API functions would be nice to have and probably easy to provide.

PyAPI_FUNC(PyObject *) PyLong_FromIntptr_t(Py_intptr_t);
PyAPI_FUNC(PyObject *) PyLong_FromUintptr_t(Py_uintptr_t);

PyAPI_FUNC(Py_intptr_t) PyLong_AsInptr_t(PyObject *);
PyAPI_FUNC(Py_uintptr_t) PyLong_AsUinptr_t(PyObject *);

Note that the given integers types should exist, as they have official counterparts in C99.

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:

There is a discussion of a similar feature in #62070, but I would argue that intptr_t and uintptr_t are much more common in real life that intmax_t.

@pitrou pitrou added type-feature A feature request or enhancement topic-C-API interpreter-core (Objects, Python, Grammar, and Parser dirs) easy labels Oct 14, 2023
@Lincoln-developer
Copy link
Contributor

Hey, I would love to work on this if you don't mind.

@pitrou
Copy link
Member Author

pitrou commented Oct 16, 2023

@encukou Does this enhancement sound like a good idea? If so, @Lincoln-developer would like to work on it.

@Lincoln-developer
Copy link
Contributor

@pitrou , are we waiting for @encukou's response on this then I start working on the issue, just inquiring. Thanks

@encukou
Copy link
Member

encukou commented Oct 18, 2023

Thanks for the propoal.
As we're forming a C-API working group to guide the evolution of the C-API, I'd prefer the proposal to be discussed on Discourse first.
Do we continue to add functions similar to the ones we already have, which are OK but could be improved, or should we switch to a new style now?

  • These functions have an ambiguous return value: when -1 is returned, the caller needs to check PyErr_Occurred. This is problematic, and against a proposed guideline. Of course, we make an exception in the name of consistency with the existing API -- but a discussion is in order.
  • We already have PyLong_{From,As}VoidPtr and PyLong_{From,As}[U]IntMax_t, which should be enough in practice. Is there a use case where these won't work? That would be a reason to add the API ASAP.
  • I'd argue that new API should use intptr_t directly, and the pre-C99 typedefs like Py_intptr_t should be phased out.

@encukou encukou removed the easy label Jul 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) topic-C-API type-feature A feature request or enhancement
Projects
None yet
Development

No branches or pull requests

3 participants