Reorganize cudf_polars expression code
#17014
Conversation
brandon-b-miller
added
feature request
| from polars.polars import _expr_nodes as pl_expr | ||
|
|
||
| from cudf_polars.containers import Column, NamedColumn | ||
| from cudf_polars.utils import dtypes, sorting | ||
| from cudf_polars.containers import Column |
There was a problem hiding this comment.
Do we want to keep this file at all?
There was a problem hiding this comment.
Additionally a few of these didn't seem to have an obvious home, maybe a misc.py?
There was a problem hiding this comment.
I think it is useful to have everything importable from one place. So yes, I think it makes sense to keep this file.
I think it would be nice if all this file did was to import the expression names into the dsl.expr namespace.
So moving the remainder makes sense to me.
How about Cast into unary.py, Ternary into ternary.py and BooleanFunction into boolean.py?
There was a problem hiding this comment.
Thanks @brandon-b-miller! This looks like a good step to me. Some small further suggestions.
| from polars.polars import _expr_nodes as pl_expr | ||
|
|
||
| from cudf_polars.containers import Column, NamedColumn | ||
| from cudf_polars.utils import dtypes, sorting | ||
| from cudf_polars.containers import Column |
There was a problem hiding this comment.
I think it is useful to have everything importable from one place. So yes, I think it makes sense to keep this file.
I think it would be nice if all this file did was to import the expression names into the dsl.expr namespace.
So moving the remainder makes sense to me.
How about Cast into unary.py, Ternary into ternary.py and BooleanFunction into boolean.py?
There was a problem hiding this comment.
The changeset is large, so I assumed that this was a pure reorg with no material changes and reviewed it as such by just skimming what went into each file. Overall this is a definite improvement and I'd be fine merging it as is. Some of the module groupings might get harder to rationalize over time, though, and some of them are already a bit more tenuous than others. That makes me wonder if we should just go with one class per module. We're already most of the way there; a couple of modules have 2-3 classes, but that's about it. WDYT? I'm OK merging this either way.
|
/merge |
|
Thanks Brandon! |
This PR seeks to break up
expr.pyinto a less unwieldy monolith.