You are viewing a plain text version of this content. The canonical link for it is here.
Posted to github@arrow.apache.org by GitBox <gi...@apache.org> on 2022/10/26 12:25:20 UTC

[GitHub] [arrow-nanoarrow] jorisvandenbossche commented on pull request #62: [Python] Basic Array class wrapping C struct (with conversion to numpy)

jorisvandenbossche commented on PR #62:
URL: https://github.com/apache/arrow-nanoarrow/pull/62#issuecomment-1291955073

   Thanks for the comments!
   
   > Just spitballing, maybe what you could have is: ... that might simplify the `own_data`/`own_ptrs`/malloc lifecycle stuff you have here.
   
   The question is also to what extent we want to expose the Array / ArrayView difference to Python users. For nanoarrow C, this distinction makes total sense, as we want something on top of the raw ArrowArray struct, which we can't change. But in Python, the Array class is already something that wraps the raw struct, so I was thinking that therefore the Python API doesn't need to directly expose this distinction to the user.
   
   
   The `own_data` isn't actually used yet. I only added it (prematurely) because I was thinking that at some point the struct might be passed to something else (eg to pyarrow), and the nanoarrow.Array class shouldn't call the release callback. Although that can (should?) probably be done by copying the struct before passing it to another consumer and setting `array.release = NULL` (https://arrow.apache.org/docs/dev/format/CDataInterface.html#moving-an-array) and in `__dealloc__` check for the release callback not being NULL whether to call it or not. 


-- 
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: github-unsubscribe@arrow.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org