Skip to content

How to deal with C-API extensions? #158

Closed

Description

@windelbouwman

Create a prototype on how to interact with a python library with a C-API extension.

See also:
https://pythoncapi.readthedocs.io/

There are some questions regarding C extensions. Primary question: how to handle this? Maybe in a similar way to cpyext?

Activity

  1. windelbouwman commented on Jan 12, 2020

    @windelbouwman
    ContributorAuthor

    Just wanted to bump this issue with a link to handlepy: https://github.com/pyhandle/hpy this might be the way to go forwards.

  2. ShadowJonathan commented on Aug 14, 2021

    @ShadowJonathan

    hpy is definitely the way, it's getting increasing support and attention from the python community

  3. encukou commented on Jan 16, 2023

    @encukou

    Hi!
    I help maintain CPython's Limited API & Stable ABI. If you want to support a subset of the C API, here's one. Not perfect -- it has decade of historical baggage itself -- but it's there. A bunch of real-world extensions use it, including PyO3 (there's even a suggestion to make it the default).

    To support it, you'd need to expose a PyObject struct with a refcount (C int) and a type (C pointer). Roughly speaking, those are the only two instances where Stable ABI extensions reach directly into memory; everything else is a function call. (Replacing refcounting by function calls turned out to be too slow, unfortunately.)

    I'd love feedback on what is hard to implement in Rust. We can add better API for the bad parts, and eventually even deprecate/remove stuff.
    Feel free to contribute to my shared notes, post here, or reach me in any other way :)

  4. arihant2math commented on Apr 5, 2025

    @arihant2math
    Contributor

    I've started with an initial implementation with #5604. Currently I haven't found a way to properly expose PyObject, but I don't see that being a massive issue for now.

  5. bschoenmaeckers commented on Apr 4, 2026

    @bschoenmaeckers
    Contributor

    I've started with an initial implementation with #5604. Currently I haven't found a way to properly expose PyObject, but I don't see that being a massive issue for now.

    Pep 803 makes PyObject an opaque pointer. So this might help improve things.

  6. encukou commented on Apr 5, 2026

    @encukou

    Rust wasn't the primary motivation for PEP 803, but I definitely had alternate implementations in mind :)

  7. arihant2math commented on Apr 5, 2026

    @arihant2math
    Contributor

    This seems interesting, if I have time, I'll take another look at a C-API.

  8. youknowone commented on Oct 6, 2026

    @youknowone
    Member

    crates/capi is the C-API prototype: pyo3-ffi-shaped headers, a growing Stable ABI surface, and tests under crates/capi. Tracking leftover functions continues in #8156.

    Closing.

    — commented by Grok 4.6

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

    A-designAbout RustPython's own implementationC-discussionA discussionE-help-wantedExtra attention is needed

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions