Return multiple structs from Rust method back to Python

[roma-glushko]

This is a follow-up question from the https://github.com/roma-glushko/notifykit/ project.

I'm mapping some events on the Rust side to different structs (e.g. CreateEvent, DeleteEvent, RenameEvent, etc.). I want those struct to get to Python world, so Python code could invoke some specific methods/attributes on them.

I'm wondering how typing should look like on the Rust/PyO3 side to make this transpire 👀

[davidhewitt]

Do you want a common base class? Or do you just want four separate #[pyclass] structs?

It's not clear to me what the question is. How you want your API to look is your choice.

[roma-glushko]

@davidhewitt

Do you want a common base class? Or do you just want four separate #[pyclass] structs?

I'm on the fence with the approach for the time being. Gonna decide later when fully get ramifications of both of them.

At this moment though, I would to understand/get the typing right. Here is what I mean:

// For instance, Let's take the No Base Class approach, All Concreate Event Classes are independent

#[pyclass]
#[derive(Debug)]
pub(crate) struct AccessEvent {
   // some fields
}

#[pyclass]
#[derive(Debug)]
pub(crate) struct CreateEvent {
   // some fields
}

#[pyclass]
#[derive(Debug)]
pub(crate) struct DeleteEvent {
   // some fields
}

#[pyclass]
pub(crate) struct Watcher {
    // some fields
}

#[pymethods]
impl Watcher {
    pub fn get(&self, py: Python) -> PyResult<?> { // Question: What should be the typing here? 
        // create and returns an instance of either AccessEvent, CreateEvent, or DeleteEvent
    }
}

On the Python end, I just want to keep isinstance() checks working e.g.isinstance(event, CreateEvent).

Should I introduce a trait and box all event instances and then pass it out of the Rust land? Or there is any other ways to get the typing working?

[davidhewitt]

Sorry for the slow reply. I think it's sufficient to just use PyObject as the return type from your function, and use e.g. create_event.into_py(py) to convert the typed instances into them.

#[pymethods]
impl Watcher {
    pub fn get(&self, py: Python) -> PyResult<PyObject> { // Question: What should be the typing here? 
        // create and returns an instance of either AccessEvent, CreateEvent, or DeleteEvent
    }
}

[roma-glushko]

Hey @davidhewitt thank you for reply!

I went with a similar solution, but:

• defined a new enum with all event types:

pub enum EventType {
    Access(access::AccessEvent),
    // ...
}

• implemented ToPyObject trait for the enum:

impl ToPyObject for EventType {
    fn to_object(&self, py: Python) -> PyObject {
        match self {
            EventType::Access(event) => event.clone().into_py(py),
            // ...
        }
    }
}

That helped me to bubble that event instance from a few rust methods all the way up to the python world 👀

On the sidebar, while I was looking for the solution, I thought it could be great to grow PyO3 example gallery, so newbies like myself would have a good source of "design" inspiration. Because before asking this question on GH Discussions, I tried to find some examples in PyO3 docs and other projects that uses PyO3 on GH, but it still took quite some time to figure it out. That might be helpful for people with similar background (e.g. not really strong Rust engineers but rather Pythonistas who got interested by potential Rust+PyO3 brings).

Let me know if that sounds interesting and if I could potentially help somehow.

[davidhewitt]

Glad you got to a solution!

On the sidebar, while I was looking for the solution, I thought it could be great to grow PyO3 example gallery, so newbies like myself would have a good source of "design" inspiration. Because before asking this question on GH Discussions, I tried to find some examples in PyO3 docs and other projects that uses PyO3 on GH, but it still took quite some time to figure it out. That might be helpful for people with similar background (e.g. not really strong Rust engineers but rather Pythonistas who got interested by potential Rust+PyO3 brings).

Let me know if that sounds interesting and if I could potentially help somehow.

Thank you for the offer; it's a great idea! We have tried to make some examples, you can see them in the examples/ subdirectory of the PyO3 repo. You can only see some small parts of these in the guide at the moment. @mejrs has been much better at making these examples than me.

I'm sure there is room for a lot of improvement here, so very happy to have all ideas and help you would like to share 🙂

[flotang-gtt]

Hi @davidhewitt I take it the answer is deprecated as of version 0.23, since now the IntoPyObject trait and subsequently into_pyobject function should be used. It looks like the answer regarding the return type also does not work anymore, right? As the into_pyobject returns a Bound, one has to reach for a replacement for the PyObject return type? What is the recommended/idiomatic way to get the behavior that is desired?

[Icxolu]

While the syntax changed a bit during the last releases, the idea behind the approach is still the same. You can for example use Bound<'py, PyAny> as the return type. You could also use .unbind() to turn your Bound back to a Py. The helper methods from IntoPyObjectExt might also come in handy.