You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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.
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.
I want to see these new code paths tested in GitHub actions, and I don't want to lose the capability we have now.
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?
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
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! 🙂
Activity
b-long commentedon Aug 29, 2026
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:
What do you think @mspiller ? Do you have certain downstream projects you can share or anything you can add about your goals?
b-long commentedon Sep 19, 2026
@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 .
matejsp commentedon Sep 20, 2026
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
b-long commentedon Sep 24, 2026
@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! 🙂