Separate evaluation logic from IR objects in cudf-polars

[rjzamora]

Description

Closes #17127

• This PR implements the proposal in [FEA] [Proposal] Separate IR evaluation logic from the IR object in cudf-polars #17127
• This change technically "breaks" with the existing IR.evaluate convention.

Checklist

• I am familiar with the Contributing Guidelines.
• New or existing tests cover these changes.
• The documentation is up to date with these changes.

[rjzamora]

Not sure if I like this any better than just using a catch-all signature. For example, mypy seems happy with:

    @classmethod
    def do_evaluate(cls, *args: Any, **kwargs: Any):
        """
        Evaluate the node (given its evaluated children), and return a dataframe.

        Parameters
        ----------
        args
            Non child arguments followed by any evaluated dataframe inputs.
        kwargs
            Key-word arguments. Should be empty!

        Returns
        -------
        DataFrame (on device) representing the evaluation of this plan
        node.

        Raises
        ------
        NotImplementedError
            If we couldn't evaluate things. Ideally this should not occur,
            since the translation phase should pick up things that we
            cannot handle.
        """
        raise NotImplementedError(
            f"Evaluation of plan {type(cls).__name__}"
        )  # pragma: no cover

[wence-]

If you remove kwargs from the signature (since there are none), it complains though

[rjzamora]

Yes, I agree it's still "off" :)

[rjzamora]

It looks like we need to account for _non_child_args elements that are normalized within __init__. (Left a few suggestions, but didn't look for everything yet)

[rjzamora]

@wence- - Just a note (still thinking on this): I've been experimenting with the next steps (beyond this PR). I'm realizing that it may not be terribly useful to separate the IR evaluation logic unless we also do the same for Expr classes. I say this because there seem to be many expressions that require reductions and/or shuffles.

[wence-]

@wence- - Just a note (still thinking on this): I've been experimenting with the next steps (beyond this PR). I'm realizing that it may not be terribly useful to separate the IR evaluation logic unless we also do the same for Expr classes. I say this because there seem to be many expressions that require reductions and/or shuffles.

Can we do that in a separate step? I would like to check the utility of this setup in the "single-partition" evaluation model first.

[rjzamora]

Can we do that in a separate step? I would like to check the utility of this setup in the "single-partition" evaluation model first.

Yes, sorry. I'm not suggesting that we do anything further in this PR (I feel that this is ready for a final review).

The goal of my previous comment was to establish that we may need to do do something similar to Expr to (cleanly) enable shuffling/reductions over multiple partitions. Single-partition execution is already easy to implement on top of this PR as it stands.

[bdice]

Minor feedback. Generally looks good to me.

[wence-]

/merge