-
Notifications
You must be signed in to change notification settings - Fork 33
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
feat: teach PyArray to compare #1090
Conversation
pyvortex/src/array.rs
Outdated
/// false, | ||
/// false | ||
/// ] | ||
fn compare(&self, other: &Bound<PyArray>, operator: &Bound<PyString>) -> PyResult<PyArray> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is a very weird python api, would this be better as a individual funtions instead of string switch?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree it is weird. PyArrow doesn't implement lt and friends but, AFAICT, nobody has complained on their issues about it. They do implement __eq__
. In the compute functions API, they do provide greater
and friends.
My best guess is that those operations are allocating so they make them available through an API that exposes the memory pool parameter. It seems like that's a way to use jemalloc or mimalloc for Arrow arrays even if the rest of the application uses some other allocator. It seems like that could be used to create an Arena for arrow arrays and do O(1) free after, say, processing a chunk of data.
Anyway, I think you're right that we should implement the operators. Even if we later provide a way to specify an allocator, the operators can continue to use the default allocator.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was mostly even thinking that even if it's not the __eq__
or __compare__
I think it's better to get rid of stringly typed operator. FWIW the C api takes an int for operator
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I switched to operators and moved the docs into the examples for technical reasons (see comment).
This slipped into #1090. I wanted to document these, but CPython limitations prevent adding doc strings to them.
This slipped into #1090. I wanted to document these, but CPython limitations prevent adding doc strings to them.
No description provided.