Py why does not have a lifetime?

[latot]

Hi all! I'm learning how to use pyo3 allowing to use python from rust mainly.

I got a lot of things but I'm still confused with Py<T>... this one does not have any lifetime, all classes must be initialized in a python instance which is where exists its memory, so why is not Py<'inst, T>? we could stop all the python interpreters and Py<T> could be a dangling reference, or I'm confused?

Thx!

[LilyFirefly]

Bound<'py, T> is the type that behaves as you expect it to here. The Py<T> type doesn't have a lifetime, but in exchange all its methods need to take a Python<'py> token, which carries the lifetime instead. A Py<T> is useful whenever holding the lifetime in the type would cause problems, most commonly in #[pyclass] structs.

[mejrs]

We also don't support subinterpreters, so we don't have to deal with it.

[latot]

Hi, right, IIRC Bound always implies have GIL, while Py does not have it, to me this is more like, I can have a Py object, and try to access it from rust even when the interpreter is already finished, so to what will it access or read?

[latot]

what happens in that case when Drop reachs python? or pyo3 keeps it running elsewhere?

[latot]

I don't know very well hoy Pyo3 handle python, its memory and interpreter, when is alive, when exists, if I make threads or process if makes new ones, or the same, how the memory is related D:

[mejrs]

The python interpreter would clean up everything, and trying to use python api after that would be UB, probably a very loud crash 🙂

[latot]

thx! I'm reading, Py today implements Sync + Send, this means pyo3 actually uses the same memory space for all threads, nice!

how is constructed in a very... really nice way, in the way of get a lot of python features in a rusty way, I don't fully get how they handle the code, in a interpreter everything we execute is remembered on it, each call, each import, each variable assignment, pyo3 does not works from this, so there I got little confused.

Like, if I start and get two classes from rust, they must be initialized on python, usually on python we set them in vars and the var is the same we replace one with the new instance of the class, so if we get two times the same class from python I would suppose they are two different instances of the new class right? and get two instances of non-class object should be equals right?

Why I'm getting so confused? because in python, the interpreter we write line by line, we can also execute python code from pyo3, when pyo3 remembers what was executed? when all works in a isolated way?

[mejrs]

this means pyo3 actually uses the same memory space for all threads, nice!

Send and Sync actually don't do anything, they are ~just annotations for the compiler to check your code is sound. But you can't specialize on whether something is Send/Sync or not,

Why I'm getting so confused?

I'd recommend reading the Python documentation about this : https://docs.python.org/3/extending/index.html

All that pyo3 does is provide an abstraction on top of this.

[magradze]

Basically, if the interpreter is already shut down, you won't get silent memory corruption or dangling references — PyO3 will either panic (if you try to bind it) or safely no-op on Drop.

You can't read anything inside Py directly anyway. You need to bind it first (.bind(py) or Python::with_gil(...)). If CPython is dead, getting the GIL/token will panic, so you never get a chance to dereference a dangling pointer.