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

Update pylibcudf testing utilities #15772

Merged

Conversation

brandon-b-miller
Copy link
Contributor

Cleans up some testing utilities for pylibcudf as suggested in #15418 (comment).

@brandon-b-miller brandon-b-miller added feature request New feature or request Python Affects Python cuDF API. non-breaking Non-breaking change labels May 17, 2024
@brandon-b-miller brandon-b-miller self-assigned this May 17, 2024
@brandon-b-miller brandon-b-miller requested a review from a team as a code owner May 17, 2024 14:33
@@ -24,28 +24,28 @@ def metadata_from_arrow_array(
return metadata


def assert_column_eq(plc_column: plc.Column, pa_array: pa.Array) -> None:
def assert_column_eq(expect: pa.Array, got: plc.Column) -> None:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to model this on

def assert_eq(left, right, **kwargs):
?

We may not always be comparing an “expected/actual” result. The assert_eq just uses left/right names. The order is perhaps better defined by the caller, and hint at that intended use case in a docstring?

Additionally, it’s not obvious that this function expects a PyArrow and a pylibcudf object. Should we normalize this to accept either argument as either type, more like assert_eq?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I updated this to be more symmetric, although I think we're stuck with having to have at least one of the objects be a pyarrow array, even if we don't know which one, unless we want to make broader changes. This is due to needing the metadata from the pyarrow array to compare nested data.

@vyasr vyasr added the pylibcudf Issues specific to the pylibcudf package label May 28, 2024
@brandon-b-miller brandon-b-miller requested review from a team as code owners May 30, 2024 01:26
@brandon-b-miller brandon-b-miller requested review from msarahan, vyasr and ttnghia and removed request for a team May 30, 2024 01:26
Copy link

copy-pr-bot bot commented May 30, 2024

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

@brandon-b-miller brandon-b-miller changed the base branch from branch-24.06 to branch-24.08 May 30, 2024 01:26
@github-actions github-actions bot added libcudf Affects libcudf (C++/CUDA) code. CMake CMake build issue labels May 30, 2024
@github-actions github-actions bot added conda Java Affects Java cuDF API. labels May 30, 2024
@brandon-b-miller brandon-b-miller removed request for a team, msarahan and ttnghia May 30, 2024 01:27
@brandon-b-miller brandon-b-miller removed libcudf Affects libcudf (C++/CUDA) code. CMake CMake build issue conda Java Affects Java cuDF API. labels May 30, 2024
@brandon-b-miller
Copy link
Contributor Author

/merge

@rapids-bot rapids-bot bot merged commit c268fc1 into rapidsai:branch-24.08 May 30, 2024
75 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request non-breaking Non-breaking change pylibcudf Issues specific to the pylibcudf package Python Affects Python cuDF API.
Projects
Archived in project
Status: Done
Development

Successfully merging this pull request may close these issues.

None yet

4 participants