Skip to content
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

Merged
merged 5 commits into from
Oct 21, 2024
Merged

feat: teach PyArray to compare #1090

merged 5 commits into from
Oct 21, 2024

Conversation

danking
Copy link
Member

@danking danking commented Oct 18, 2024

No description provided.

@danking danking marked this pull request as ready for review October 18, 2024 20:39
@danking danking enabled auto-merge (squash) October 18, 2024 20:39
/// false,
/// false
/// ]
fn compare(&self, other: &Bound<PyArray>, operator: &Bound<PyString>) -> PyResult<PyArray> {
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

@robert3005 robert3005 Oct 21, 2024

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

Copy link
Member Author

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).

@danking danking merged commit 36a7a94 into develop Oct 21, 2024
5 checks passed
@danking danking deleted the dk/pyvortex-compare branch October 21, 2024 19:04
danking added a commit that referenced this pull request Oct 21, 2024
This slipped into #1090. I wanted to document these, but CPython
limitations prevent adding doc strings to them.
danking added a commit that referenced this pull request Oct 21, 2024
This slipped into #1090. I wanted to document these, but CPython
limitations prevent adding doc strings to them.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants