Skip to content

pybindgen replacement #408

Description

@mspiller

Would it be possible to replace pybindgen with more modern and maintaned pybind11?

What are downsides?

Activity

  1. b-long commented on Aug 29, 2026

    @b-long
    Member

    Yes!

    We should absolutely replace it. I see no obvious downside.

    My only hesitation is that we proceed with caution, and respect our existing users. We should aim to provide a clear and simple upgrade path.

    I suppose, to start, I have two main thoughts:

    1. What about alternatives, like cffi or directly generating code to target the CPython C API? I can think of arguments against these, but maybe I'm missing some information.
    2. I'd like us to proceed slowly and with certain intention/criteria. For instance, I'd like to see a small core of the new machinery built (the smaller the better), enabled by an environment variable or other flag, which downstream projects can enable for testing and adoption.
      1. As a subpart here, I don't want to see a PR which modifies 40 files, with 50,000 lines changed. Let's do this carefully, I'm happy to create or accept a PR that changes 4 files and maybe 500 lines. I don't mean these numbers as requirements, just examples.
      2. I want to see these new code paths tested in GitHub actions, and I don't want to lose the capability we have now.
      3. I would hope that we can preserve as much of the existing test coverage. Perhaps all existing tests?

    What do you think @mspiller ? Do you have certain downstream projects you can share or anything you can add about your goals?

  2. b-long commented on Sep 19, 2026

    @b-long
    Member

    @mspiller I've started this work, and I would genuinely appreciate any feedback on the approach.

    See: #409

    I am wondering if the scope of #409 should be expanded to consider / investigate #256 .

  3. matejsp commented on Sep 20, 2026

    @matejsp

    Oh really impressed. I love the solution multiple backends. Just worry about long term maintenance burden.
    cffi is very nice addition. It makes me wonder if also python ctypes would also be a candidate (because you don't need any external dependencies).

    I will do some testing and see how it behaves in the following days

  4. b-long commented on Sep 24, 2026

    @b-long
    Member

    @matejsp Thank you 👍

    Of course, it is still a work in progress. Great point about maintenance burden, I'll try to proceed with care. Perhaps all "new" backends can be labeled experimental for a time and then eventually (2027?) the community could pick a winner?

    I will do what I can to take guidance & feedback from the community, so please let me know what you think! 🙂

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

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions