-
Notifications
You must be signed in to change notification settings - Fork 915
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
Rework Scalar
imports
#10791
Rework Scalar
imports
#10791
Conversation
Codecov Report
@@ Coverage Diff @@
## branch-22.06 #10791 +/- ##
================================================
- Coverage 86.40% 86.29% -0.12%
================================================
Files 143 144 +1
Lines 22444 22491 +47
================================================
+ Hits 19393 19408 +15
- Misses 3051 3083 +32
Continue to review full report at Codecov.
|
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.
One request that can be addressed in a follow-up, otherwise LGTM.
isinstance(other, np.generic) or other.is_valid | ||
) | ||
if not valid: | ||
return Scalar(None, dtype=out_dtype) |
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 realize it's not in scope, so I'd be perfectly happy with a follow-up, but this seems like an important case to have tested somewhere. It's basically for any binary op between two scalars where one is NA, right? I'm surprised that's not tested, I guess because we only test column + scalar?
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.
(Approving but would also like to see tests for this at some point.)
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 thought I'd leave a review summary but then I was like NA.
from cudf.core.dtypes import ListDtype, StructDtype | ||
from cudf.core.index import BaseIndex | ||
from cudf.core.missing import NA |
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.
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.
This is a really great question. We use cudf.NA
almost everywhere, but should we? In some ways it feels like it might fit the "onion model" a bit better if scalar.py
didn't mention the top level cudf
namespace anywhere.
I think there's probably plenty of places I have used cudf.NA
throughout the codebase as a convenience since those places already have cudf
imported, but I realize now that it has the negative consequence of further entrenching the need for import cudf
in those places, which is part of what I think gives rise to these import issues.
Is this way off base? I am happy to put in a PR that addresses this for NA
across the codebase as a follow up if that's what we think should happen, and just imports from missing
.
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.
In the long run I would love to get rid of import cudf
almost everywhere. It is a code smell that almost always (there are always exceptions) indicates circular dependencies that should not exist. Unfortunately a lot of those circular dependencies are baked deeply into our code right now and are hard to excise. If you could get rid of these on a case-by-case basis (in this instance, for cudf.NA
), I think that would be good for us in the long run.
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.
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.
Removing import cudf
sounds fine to me! Could we make an issue to document the plan before resolving this? (I would do it but I’m on mobile at the moment.)
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 raised #10820 regarding this. I'll tackle this for NA
first after this PR is merged, after which it should be importable from missing
. From there I'll start probing what it takes to address this more generally.
Co-authored-by: Bradley Dice <[email protected]>
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.
Approving — would like to see a test added (in a later PR, perhaps) and an issue filed for the plan to remove internal uses of import cudf
.
isinstance(other, np.generic) or other.is_valid | ||
) | ||
if not valid: | ||
return Scalar(None, dtype=out_dtype) |
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.
(Approving but would also like to see tests for this at some point.)
@gpucibot merge |
…0821) This PR changes cuDF so `NA` isn't used around the codebase from the top level `cudf` namespace and rather is imported directly from `missing`. This is part of #10820 and comes as a follow up to #10791 (comment) Authors: - https://github.com/brandon-b-miller Approvers: - GALI PREM SAGAR (https://github.com/galipremsagar) URL: #10821
Add tests for binaryops between two null scalars as per #10791 (comment) This is technically `1307` tests but they only take about 5 seconds to run. Authors: - https://github.com/brandon-b-miller Approvers: - GALI PREM SAGAR (https://github.com/galipremsagar) URL: #10828
This PR changes the way things are imported in our scalar code such that it's less prone to circular import issues. For instance before this we can't make
NA
the default value of a kwarg for, say, anything incolumn.py
.