PyO3: Python Rust binding
github.com
github.com
For anyone reading the comments first, this is a fork of rust-cpython. The motivation for the fork is linked from the Readme: https://github.com/PyO3/pyo3/issues/55
What happened with the fork: in May @fafhrd91 contacted me about joining the project. When I had time to consider his request (on the following weekend), he had already forked the project and deleted all his original pull requests. He even deleted his bug report about that segfault he keeps mentioning when comparing PyO3 to rust-cpython.
On the technical side, the API changes in PyO3 are interesting. It's kind of a return to my original design (with `&'a PyObject<'p>`), but he makes it work with just a single lifetime by using a "release pool" that temporarily holds ownership over the python references. This does make the API significantly nicer to use, at the cost of leaking any Python objects until the GIL is released / until the extension module returns to the interpreter. For the typical extension module usecase, this doesn't hurt much. But a long-running loop that allocates a temporary Python object each iteration might run out of memory due to this design.
as for leaking refs, it maybe be fixed by introducing nested "Pool" objects. objective-c runtime has similar concepts and same problem with long running loops.
That is just sleazy :/.
I certainly won't use this fork for social reasons.
impl PyList {
fn new(py: Python) -> PyList {...}
fn get_item(&self, py: Python, index: isize) -> PyObject {...}
}
impl PyList {
fn new(py: Python) -> &PyList {...}
fn get_item(&self, index: isize) -> &PyObject {...}
}
In PyO3 (second snippet) that does not seem to be the case, the object itself has a lifetime dependency on holding the GIL. So you can't e.g. release the GIL to do native processing if you'll still need the native objects afterwards.