-
Notifications
You must be signed in to change notification settings - Fork 111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow for fetching entire []byte
slice as bytes
#323
Comments
This could be achieved by using a string type presumably? The semantics of the []byte would be lost if it was not directly writable on the python side. |
My understanding is that a
I suppose there's no way of forcing a Go |
I'm not sufficiently up on the relevant standards in Python for how this all works, so I can't really judge, but it sounds like we might want to have it work in different ways depending on the use case.. We do have the ability to flag things with some kind of comment directive I believe, so that might be an option. I can't quite remember where this is used but I believe it determines how an |
This is a great issue for someone to work on! The current model is that Go owns all the data structures exposed by gopy, which continue to be managed by its GC etc, and are accessed exclusively by the (auto generated) handle. To do something more efficient, gopy could expose a method that returns an unsafe pointer and a length into any slice's raw memory ( |
Fixed by #342 |
Currently,
[]byte
slices in Go are presented in Python as a custom type,Slice_byte
, which allows for iterating over and fetching individual byte values from the underlying slice. However, this is rather inefficient for large slices, as each iteration requires FFI calls between Python, C, and Go (i.e. against theSlice_byte_elem
function).It might, therefore, be more efficient to allow for returning the entire
[]byte
slice as a Pythonbytes
object, as a single FFI call, perhaps as aC.CString
. Even if each (or the first) call creates a copy, the latency and CPU time tradeoff should be a sufficient improvement overall.The text was updated successfully, but these errors were encountered: