Add py::array::size() function?

[adler-j]

Currently if I want to access a parameter such as array length, the best method to my knowledge is

size_t size = target.request().count;

There are two problems with this. First, the corresponding python name is size, so renaming count -> size would be nice.

Further, wouldnt It be nice to have access to this as a free function?

size_t size = target.size()

[wjakob]

Not sure I agree. Having both an 'itemsize' and 'size' field is highly confusing -- calling it 'count' disambiguates which one is a size in bytes, and which one is the element count.

The problem with directly exposing size() is that it's an expensive operation. You have to request a buffer view via PyObject_GetBuffer and release it right afterwards (these are heavy operations). It's better to request it only once, and to encourage this kind of usage via the API.

[adler-j]

Not sure I agree. Having both an 'itemsize' and 'size' field is highly confusing -- calling it 'count' disambiguates which one is a size in bytes, and which one is the element count.

I would agree if this was a "free standing" library and we were free to select new names, but (imo) numpy compatibility is a very strong feature here. In addition size is the name used in all stl containers in c++, while count is used for counting something, such as in std::count.

The problem with directly exposing size() is that it's an expensive operation. You have to request a buffer view via PyObject_GetBuffer and release it right afterwards (these are heavy operations). It's better to request it only once, and to encourage this kind of usage via the API.

If that is the case, I agree, but Isn't PyArray_SIZE decently fast? At worst you incur the same overhead that numpy would, which for many users is ok.

[wjakob]

That's a good point -- if it's possible to replicate the behavior of PyArray_SIZE without depending numpy headers, then I'm open to adding a function to pybind11::array. However, this would not work for the bare bones pybind11::buffer interface.

[adler-j]

Regarding the rename, the issue started more ambitious: allow access of each buffer member one-by-one instead of through the buffer_info protocol.

[wjakob]

The issue I see here is that it's impossible to provide these fast access operations to structural data for non-NumPy plain buffer objects.

On the other hand, the bindings of pybind11::array should be compatible with pybind11::buffer. Not necessarily impossible to do, but something to take into account.

[adler-j]

I had a bug that seems to be related to this, when calling the request function multiple times the buffer view was free'd repeatedly. I fixed this in pull #45.