Intrusive counters and std::vector<>

[jdumas]

Hi,

I've been reading about the limitations of STL vector bindings, and I'd like to implement a solution using nb::intrusive_counter. One issue I'm running into, is that nb::ref<T> has the same API as pointer T *. But I'd like my code to behave as a std::vector<T> when Python bindings are disabled (i.e. we only use the C++ API). Would it be possible to have an equivalent to std::reference_wrapper<> for nanobind ref-counted types that would behave more transparently from the C++ perspective?

It should be just a matter of adding a const/non-const operator T&() { return *m_ptr; } to the existing nb::ref<> implementation, but I'm curious if there are any gotcha to know about?

[jdumas]

Ok so for the sake of the discussion, here are two minimal examples using nanobind and pybind11:

• Nanobind unit tests and binding code.
• Pybind11 unit tests and binding code.

I believe nanobind changed its default return policy from reference to copy following this bug report, so I'm not surprised by the difference in behavior.

At the end of the day, I'm trying to create bindings for a json-like object that feels Pythonic. Ideally I'd use type-casters (so types behaves more naturally in Python), but being unable to update the underlying data makes it very challenging to use (which is this limitation but when editing fields rather than calling functions).

[jdumas]

I see. I might have to change container altogether to avoid std::vector<> in favor of memory stability then.

That being said, this makes it very difficult to work with type-casters and getters/setters. If you consider the following example:

struct Document {
    nlohmann::json data;
};

NB_MODULE(nanobind_example_ext, m) {
    nb::class_<Document>(m, "Document")
        .def(nb::init<>())
        .def_rw("data", &Document::data, nb::rv_policy::reference_internal);
}

Imagine that nlohmann::json is handled with a type-caster e.g. from this repo. Then the following Python code will not work as expected:

doc = m.Document()

doc.data = {"key0": [0, 1, 2]} # Works, setter
doc.data |= {"key1": "value" } # Doesn't update the dict, because the type-caster for doc.data copies the content.

The only "solution" I see to this is to have an explicit set_data() and get_data() method to retrieve the json dictionary, to make it clear "getting" always returns a copy. But that doesn't feel very Pythonic. I'm wondering if you had any suggestion around that?

[wjakob]

I think that |= is translated internally into a read, |, and write. So I suspect in this case the operation will work.

[jdumas]

Hmm maybe but I doubt it'll work with dict.update() though. Here is a full example adapted from the nanobind_example repo. I think the nanobind_json type-caster has some limitations because the unit tests are currently failing for both the assign and the |= test... But the .update() fails as expected:

        foo = m.Document()
        foo.data = dict()

        foo.data.update({"extension0": {"key": [0, 1, 2]}})
>       assert len(foo.data) == 1
E       assert 0 == 1
E        +  where 0 = len({})
E        +    where {} = <nanobind_example.nanobind_example_ext.Document object at 0x101640a50>.data

[wjakob]

Yep, that is expected. It is what it is -- the limitations of the current approach are clear, but there isn't an obvious alternative.

Just hypothetically suppose, you pursued the "wrapper" route: you would need a type that intercepts every possible attribute/method access, indexing, etc, and which stores a base pointer to the underlying array and the entry. Calling .update() would then dynamically resolve the current memory address and apply the update.

One reason why I did not pursue this kind of approach is composability: What if the data structure is nested, and we access an element deeper inside? (e.g. foo.data.element[5].member.update(..)). To protect from any memory layout changes of any parent data structures, we would need a very flexible wrapper object that can encode such nested access. The implementation detail (that there is a wrapper) would also leak into the type system and make debugging/documentation confusing.

[wjakob]

By the way, did you see what I wrote above? You can totally call nb::bind_vector<> with a custom rv_policy, and then it will behave exactly like pybind11. It's just a bad design IMO and will come to haunt you.

[jdumas]

One reason why I did not pursue this kind of approach is composability: What if the data structure is nested, and we access an element deeper inside? (e.g. foo.data.element[5].member.update(..)). To protect from any memory layout changes of any parent data structures, we would need a very flexible wrapper object that can encode such nested access. The implementation detail (that there is a wrapper) would also leak into the type system and make debugging/documentation confusing.

Yes I understand the issue. It's still a bit frustrating imho that there isn't a good way to interrop naturally between Python dict and C++ json-like structs.

By the way, did you see what I wrote above? You can totally call nb::bind_vector<> with a custom rv_policy, and then it will behave exactly like pybind11. It's just a bad design IMO and will come to haunt you.

Yes, thanks! I also replied I might have to change container altogether to avoid std::vector<> in favor of memory stability then.. But I think I'll simply use a std::vector<std::shared_ptr<T>> to provide memory stability.