jorisvandenbossche opened a new issue, #319: URL: https://github.com/apache/arrow-nanoarrow/issues/319
Currently, the python bindings essentially work like the following (saying it for Array, but the same structure is used for Schema and ArrayStream): - `ArrowArrayHolder`: holds the struct and ensures it is released on deallocation - `Array`: ArrowArray wrapper, exposing more or less literally the fields of the C ABI - `ArrayView`: more user-friendly wrapper around Array with additional helper methods (eg getting the buffers as python objects, ..) And then the entry point for users `nanoarrow.array(..)` creates an `Array` and you need to call the `view()` method to get the more interesting ArrayView class. From the point of view of wrapping the nanoarrow C code closely, this structure makes a lot of sense. But for a user of the Python API this seems a bit verbose. I think the main entry point for the user should be what is now called the view class, and eg giving the ability to still get the "raw" ArrowArray wrapper class. So we could also have something like: - `Array`: main entry-point for users and this class combines the current methods/attributes from Array + the helper methods from ArrayView - `ArrowArrayHolder` or `CArrowArray`: merger of what is now `ArrowArrayHolder` and `Array`, responsible for the memory of the actual struct and releasing it, as well as exposing the basic fields (I haven't thought through what this means for the other classes we have, eg the Children classes, but already wanted to put some thoughts here) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
