Version bump pybind11 -> 3.0.2

[franzpoeschel]

This contains a workaround to this restriction introduced by 3.0.2:

_deps/fetchedpybind11-src/include/pybind11/pybind11.h:2462:25: error: static assertion failed: def_property family does not currently support keep_alive. Use a py::cpp_function instead

Note for backporting:

Relax the required minimum version back to the old minimum version again for a backport.

[ax3l]

Oh wow, I was not aware of that buggy interface.

Thanks for updating and keeping the API (now safe)!
pybind/pybind11#5533

[ax3l]

Ooops, homebrew hotfix x-refed and closed this by accident.

[ax3l]

Idea: we can simplify this with the details here?
https://pybind11.readthedocs.io/en/stable/advanced/functions.html

[franzpoeschel]

Idea: we can simplify this with the details here? https://pybind11.readthedocs.io/en/stable/advanced/functions.html

Done, thanks for the suggestion

[gentlegiantJGC]

I think you might have the keep_alive arguments the wrong way around.
Your docstring says return value must be freed before Iteration ie return value must keep self alive but py::keep_alive<1, 0>() makes self keep the return value alive.
Is keep_alive even needed here if you are returning a copy?
Also look into return_value_policy::reference_internal which is the default policy for def_property and family.

I suggest you add some tests using weakref to ensure the lifespan behaves like you want.

[franzpoeschel]

I think you might have the keep_alive arguments the wrong way around. Your docstring says return value must be freed before Iteration ie return value must keep self alive but py::keep_alive<1, 0>() makes self keep the return value alive.

Thank you for checking, I'll add a fix for it. If I remember correctly, the current state of things might have been a result of keepalives not working, trying some different approaches and sticking with a version that worked somewhat. Maybe related to the issue connecting keepalive specifications with properties that now came up.

Is keep_alive even needed here if you are returning a copy? Also look into return_value_policy::reference_internal which is the default policy for def_property and family.

Yep, it still is, since our C++ API requires manually keeping the root object alive, and the handles do not do that even when copied. The Python API should not require this.

I suggest you add some tests using weakref to ensure the lifespan behaves like you want.

I will try if I can make such a test work now