paleolimbot commented on code in PR #378:
URL: https://github.com/apache/arrow-nanoarrow/pull/378#discussion_r1484931533
##########
python/src/nanoarrow/c_lib.py:
##########
@@ -257,7 +465,74 @@ def c_array_view(obj, requested_schema=None) -> CArrayView:
return CArrayView.from_cpu_array(c_array(obj, requested_schema))
-def allocate_c_schema():
+def c_buffer(obj) -> CBuffer:
+ """Owning, read-only ArrowBuffer wrapper
+
+ Wraps obj in nanoarrow's owning buffer structure, the ArrowBuffer,
Review Comment:
It would definitely be more Pythonic! Feel free to push back here, but the
constructors for all the objects are like this for two reasons.
First, the docstring is inaccessible to IDEs if they live in Cython (or
maybe: it would require learning a bunch of things I don't know how to do to
make them accessible). Right now if you open VSCode with a script containing
`import nanoarrow as na`, `na.c_buffer(` will display a pop-up with the
docstring, whereas `na.c_lib.CArray(` will not.
The second reason is that iterating in Cython is slow: every time you make a
change, you have to wait about ten seconds to rebuild and fix any syntax
errors. With an editable install, changes in Python are instantaneous.
Both of these things mean that I've actively tried to avoid Cython, which
results in a slightly non-Pythonic interface for classes that have to live
there (because they manage memory with C calls or because they implement the
buffer protocol, neither of which are easy or possible in Python).
--
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]