How to expose raw memory without numpy

[yobeonline]

I have a situation similar to what is described in #2271. In short, I expose a C++ object that has a std:vector<std::vector<T>> columns attribute. A member function taking an index returns the selected nested vector as a numpy array:

auto get_array(size_t i) const {
  return py::array_t<T>{columns[i].size(), columns[i], py::cast(*this)};
}

Out of curiosity, I am trying to do it without the numpy dependency. I believe it means my get_array function should now return a py::memoryview instance:

auto get_memview(size_t i) const {
  return py::memoryview::frum_buffer(
    columns[i].datat(),
    sizeof(T),
    py::format_descriptor<T>::format(),
    {data[i].size()},
    {sizeof(T)},
    true,
  );
}

My problem is that I can't find how to pass the py::cast(*this) reference to tie the lifetime of this and the memoryview object. I have reached the point where I doubt memoryviews were design to do what I am trying to do and am wondering what I should use instead or if it is even possible to not use numpy arrays.

[nazeeh111]

Yes, a NumPy-free view is possible. The missing piece is an exporter object that implements Python's buffer protocol and retains your owner. memoryview::from_buffer() wraps a raw pointer without an owner argument; its documentation explicitly leaves the buffer lifetime to you.

For example, using double for T and Table for your existing C++ class:

#include <pybind11/pybind11.h>
#include <cstddef>
#include <utility>
namespace py = pybind11;

struct ColumnView {
    py::object owner;
    const double* data;
    py::ssize_t size;
};

// Inside PYBIND11_MODULE, before binding get_memview:
py::class_<ColumnView>(m, "_ColumnView", py::buffer_protocol())
    .def_buffer([](const ColumnView& v) {
        return py::buffer_info(v.data, v.size, true); // readonly
    });

// Add this .def to your existing Table binding:
.def("get_memview", [](py::object self, std::size_t i) {
    const auto& column = self.cast<const Table&>().columns.at(i);
    return py::memoryview(py::cast(ColumnView{
        std::move(self), column.data(),
        static_cast<py::ssize_t>(column.size())
    }));
})

The reference chain is memoryview -> ColumnView -> original Python owner. Constructing a memoryview from a buffer-exporting object uses that object's buffer, whose obj reference keeps the exporter alive. Derived views retain that buffer too:

v = table.get_memview(0)
s = v[1:]
del v, table
print(s.tolist())  # owner is still retained

Avoid relying solely on py::keep_alive<0, 1>() on a raw from_buffer() return: that ties the owner to the original memoryview object. In a local test, deleting that view released the owner while a slice still existed. The exporter approach retained the owner until the last derived view was released.

Keep the selected vector's size, allocation and element lifetimes stable until every view is released: no resize, erase, clear or replacement. Synchronize any C++ element updates with readers. Keeping Table alive does not itself prevent those operations; this also applies to your NumPy-backed view. readonly prevents writes through the Python view, not changes from C++.

This pattern was compiled with pybind11 3.1.0 and Python 3.14.7, without importing NumPy. Checks covered pointer identity, visible C++ element updates, empty columns, read-only behavior, and owner lifetime through slices/casts after releasing the original view.