How do I call the Python id function from Rust?

[LilyAcorn]

In my specific case, I have an instance of PyFrame. I want to get it's id for use as a HashMap key.

[birkenfeld]

Since the id is simply the object's memory address, you can use obj.as_ptr() from the AsPyPointer trait.

Otherwise, you can get at id (or other built-in functions) using py.eval("id", None, None).

[LilyAcorn]

That doesn't play nicely with #[pyclass]:

error[E0277]: `*mut Py<pyo3::PyAny>` cannot be sent between threads safely                                       
    --> src/lib.rs:654:5
     |
654  |     #[pyclass]
     |     ^^^^^^^^^^ `*mut Py<pyo3::PyAny>` cannot be sent between threads safely
     |
     = help: within `(*mut Py<pyo3::PyAny>, std::string::String)`, the trait `Send` is not implemented for `*mut Py<pyo3::PyAny>`
     = help: the trait `Send` is implemented for `Py<T>`
     = note: required because it appears within the type `(*mut Py<pyo3::PyAny>, std::string::String)`
     = note: required for `hashbrown::raw::RawTable<(*mut Py<pyo3::PyAny>, std::string::String)>` to implement `Send`
     = note: required because it appears within the type `hashbrown::map::HashMap<*mut Py<pyo3::PyAny>, std::string::String, RandomState>`
     = note: required because it appears within the type `HashMap<*mut Py<pyo3::PyAny>, std::string::String>`
note: required because it appears within the type `MyStruct`
    --> src/lib.rs:656:12

[adamreichold]

Ah, I see. Raw pointers are not Send by default but that is rather a lint than a hard error (because you still need unsafe if you were to dereference them).

I think there are multiple options:

• Use a newtype #[derive(PartialEq, Eq, Hash)] struct FrameKey(*mut PyObject); and manually unsafe impl Send for FrameKey {}.
• Use usize instead of i32 which should always suffice to store the address part of a pointer.
• Use #[pyclass(unsendable)] to avoid the Send requirement and you can expect the Python side to honour this.

Personally, I would probably go for usize in this case. (I am not sure if the additional capability bits on e.g. CHERI should actually be part of this key.)

[mejrs]

The first option is what I'd recommend.

[LilyAcorn]

I'm going with usize since it matches the python implementation and I understand it!

[adamreichold]

The first option is what I'd recommend.

If we are giving conflicting advice, I guess we should add rationales so that future readers can understand why we recommended what we did. @mejrs I'll give it a try for both options but please correct me if I am wrong.

Using usize is close to your existing code and is simple. The possibly loss of information w.r.t. extra pointers is unlikely to be practically relevant. On downside, this is somewhat type blind and strictly speaking unnecessary as *mut PyObject works using the right incantations.

Using a FrameKey newtype is guaranteed to not lose any information and since raw pointers not being Send is only a lint, asserting that it actually is safe in the specific circumstances is straight forward. On the other hand, writing this is quite a bit of boiler plate and it does add an unsafe block even though there are fully safe alternatives (as we never want to dereference these pointers).