Progress in wrangling the Python C API

It seems to me that the Python C API would probably benefit from formalising the ownership and mutability rules to match Rust's - not just because it makes interfacing Python with Rust easier, but because it would improve the lot of /everything/ interfacing with Python. Rust's rules are simple, fairly easy to reason about, and powerful, even if you don't have the whole language enforcing them - it seems like it'd be a good model for /anything/ that wants to manage access to shared memory, particularly across a natural boundary like an extension API.

If I've understood things from previous discussions about this properly (and option 3 in your comment supports this) the API already kind of supports some of this, though not really very well - from memory it might be doable with some new flags that plugins supporting the new model would set and check, while old plugins would ignore/not set and get the same behaviour they do now. Then it's just a matter of making sure the Python side maintained its end of the new model, and off you go. Of course, mixing new and old would probably Not Work(tm) in interesting ways, but mixing and matching ABIs is rarely a good idea . . .

You probably wouldn't want to try and enforce the rules with locking and so forth (though in the no-gil world maybe it'd be necessary?) - trusting that the plugin didn't ignore the flags that were set, or lie about the flags /it/ set, would seem like the best approach. After all, it's at least making explicit promises, as it stands there are no promises at all, let alone actual guard rails anywhere.

It may also be the case that changes on the Python side to support the new model would break some users - but isn't that kind of the situation anyone using the current C API has to deal with across major version changes? And if the whole C API is being reworked (hopefully also properly formalised, stabilised and documented) then isn't that a great time to implement this kind of breaking change?