Hopefully failing tests here: https://github.com/willstott101/gz-math/actions/runs/3016276863

I mentioned in the original PR text:

I haven't signed off yet cause I want feedback on making data non-private - is there another way to access that data from the python header - some sort of friend thing?

I'm not happy to sign this off yet so I won't sign off the commits.

Takes a really long time for the CI to roll through, here's latest runs (since they're not allowed to run here by the looks of it?)

Expected failing new tests: https://github.com/willstott101/gz-math/actions/runs/3016796871
After patches to fix those tests: https://github.com/willstott101/gz-math/actions/runs/3020976151

since they're not allowed to run here by the looks of it?

Since it was your first time contributing they had to be manually approved, they will run now (and I don't believe you need approval in the future)

Ok finally happy (with everything but making data public).

• failing tests before patch: https://github.com/willstott101/gz-math/actions/runs/3021342616
• passing tests after patch: https://github.com/willstott101/gz-math/actions/runs/3021400720

Resulting buffers are contiguous, index in the same way whether using numpy, memoryview, or Matrix*.__call__.

This means we can go from Matrix -> flat list with () requires contiguous to cast:
memoryview(m).cast('b', (4 * 4 * 8,)).cast('d', (4 * 4,)).tolist()

And matrix to structured list with (does not require contiguous):
memoryview(m).tolist()

Ok finally happy (with everything but making data public).

Did you have a workaround for this yet?

Nope, I'm not much of a c++ guy, doubt I'll get to digging to be honest - but happy to update if someone has an idea

I've had a bit of a dig into this, and I don't see any way to make the python binding have access to the private member. It just doesn't seem possible with the way the templates are used.

I don't think making data public is all that bad, would you be tempted to accept this MR with making the data var public?

I've signed off the commits

How about using accessor functions?

To what end? This PR is about exposing the underlying multi-dimensional array to python. Accessor functions won't enable that.

The buffer protocol is commonly used for converting to/from numpy arrays for instance. I happen to be using it to get the data as a python list, though that could of course be done slowly with accessor functions, exposing the underlying data using the buffer protocol is more flexible, potentially faster in some scenarios and is very common for matrix/array programming in python.

I've had a bit of a dig into this, and I don't see any way to make the python binding have access to the private member. It just doesn't seem possible with the way the templates are used.

I don't think making data public is all that bad, would you be tempted to accept this MR with making the data var public?

I would prefer adding an accessor method that returns the data pointer, since it is easier to deprecate methods than member variables. I think we've avoided exposing the raw data pointer to help protect from invalid memory access, but it sounds like there's some demand for it, so we could consider add some warnings in the documentation to be careful with the memory access.

Codecov Report

Merging #498 (a361471) into gz-math7 (b9d69e5) will increase coverage by 0.00%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           gz-math7     #498   +/-   ##
=========================================
  Coverage     99.70%   99.70%           
=========================================
  Files            77       77           
  Lines          7007     7026   +19     
=========================================
+ Hits           6986     7005   +19     
  Misses           21       21           

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

I see, I hadn't considered deprecation processes. That makes sense, thank you for explaining.

I understand there might be some hesitance with exposing the underlying array. Definitely rarely need to, particularly when used in a language with very fast (or even inlined) function calls. Sadly python isn't that :(

Would the return type simply be T*? Any appetite for std::array<std::array<T, 3>, 3>& instead? Either using reinterpret_cast, or actually changing the underlying member type.

Perhaps that would help reduce the likelyhood of using it incorrectly. And also make it easier to support a strongly-typed copying getter/setter pair if the reference returning method had to be deprecated.

Either way I'm happy to update this MR with a reference/pointer returning method.

Closing in favour of #524