Skip to content

Provide PyLong conversions with Py_(u)intptr_t #110863

Closed

Description

@pitrou

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.

Activity

  1. Lincoln-developer commented on Oct 16, 2023

    @Lincoln-developer
    Contributor

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

  2. pitrou commented on Oct 16, 2023

    @pitrou
    MemberAuthor

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

  3. Lincoln-developer commented on Oct 18, 2023

    @Lincoln-developer
    Contributor

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

  4. encukou commented on Oct 18, 2023

    @encukou
    Member

    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.
  5. vstinner commented on Jan 27, 2025

    @vstinner
    Member

    Somehow related, Python 3.14 adds the following functions:

    • PyLong_AsInt32()
    • PyLong_AsInt64()
    • PyLong_AsUInt32()
    • PyLong_AsUInt64()
    • PyLong_FromInt32()
    • PyLong_FromInt64()
    • PyLong_FromUInt32()
    • PyLong_FromUInt64()
  6. vstinner commented on Jan 28, 2025

    @vstinner
    Member

    See also issue gh-62070 for PyLong_FromIntMax_t() and PyLong_FromUintMax_t().

  7. encukou commented on Jan 28, 2025

    @encukou
    Member

    Since 3.13 you can use PyLong_{From,To}NativeBytes with sizeof(intptr_t). Is that enough for your use case?

  8. encukou commented on Feb 4, 2025

    @encukou
    Member

    If not, please reopen :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions