__setstate__ in a scenario with nb::new_

[wojdyr]

I'm making bindings for externally allocated objects. Let's say struct Item can be accessed with:

Item* get_pointer_to_item(const std::string& s);

Following the docs, I use nb::new_ instead of nb::init.

nb::class_<Item>(m, "Item")
  .def(nb::new_(&get_pointer_to_item), nb::rv_policy::reference)

and it works well.

Any idea how it can be unpickled in a similar way?
Is there a way to set the instance of a C++ object from __setstate__?

[wojdyr]

I found a workaround. __reduce__ (instead of __getstate__ +__setstate__) can redirect unpickling to a Python constructor.

    .def("__reduce__", [](const Item& self) {
        return nb::make_tuple(nb::type<Item>(), nb::make_tuple(self.arg_for_ctor()));
    })

I'm still curious if there are more efficient ways to do it.

[oremanj]

You might also be able to get away with something like:

nb::class_<Item>(m, "Item")
  .def(nb::new_(&get_pointer_to_item), nb::rv_policy::reference)
  .def("__getnewargs__", [](const Item& self) { return nb::make_tuple(self.arg_for_ctor()); })

But options are pretty limited overall; nanobind does not permit the C++ object address associated with a given Python instance to change during the Python instance's lifetime, which is not a good fit for how pickle most prefers to operate (at least when combined with factory functions like this). I proposed a loosening of this restriction in #474 which was not accepted, but you might find the code interesting if this sort of "call a factory function on unpickle" logic is worth maintaining a fork.