Migrate round to pylibcudf

[lithomas1]

Description

xref #15162

Migrate round.pxd to use pylibcudf APIs.

Checklist

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

[lithomas1]

Do the strings after the enum values mean anything (e.g. "cudf::rounding_method::HALF_UP") or are they purely cosmetic?

(asking since I don't want to unintentionally change behavior by changing this here)

[vyasr]

The strings are meaningful, but removing them is the right answer. The strings are a way to alias the names of Cython objects so that they appear differently in generated C code. IOW when you write cdef rounding_method x = HALF_UP in Cython code, that will translate to C code that says enum rounding_method X = cudf::rounding_method::HALF_UP. The reason that we previously need this in enums in our Cython is because prior to version 3.0 Cython did not support C++ scoped enumerations (enum class), but all of our C++ enums are defined that way, so the alias was the only way to trick Cython into generating the code that we needed (with raw C enums you don't need to do cudf::rounding_method::HALF_UP, you can just do cudf::HALF_UP because the enum doesn't create it's own namespace). By switching to using an enum class here we remove the need for that.

[vyasr]

The strings are meaningful, but removing them is the right answer. The strings are a way to alias the names of Cython objects so that they appear differently in generated C code. IOW when you write cdef rounding_method x = HALF_UP in Cython code, that will translate to C code that says enum rounding_method X = cudf::rounding_method::HALF_UP. The reason that we previously need this in enums in our Cython is because prior to version 3.0 Cython did not support C++ scoped enumerations (enum class), but all of our C++ enums are defined that way, so the alias was the only way to trick Cython into generating the code that we needed (with raw C enums you don't need to do cudf::rounding_method::HALF_UP, you can just do cudf::HALF_UP because the enum doesn't create it's own namespace). By switching to using an enum class here we remove the need for that.

[vyasr]

As a general rule we want to avoid cimporting anything from pylibcudf into cudf._lib. The goal is for cudf to become pure Python, or as close to it as possible (we may still use Cython, but primarily for cudf-specific internal optimizations; calls to the libcudf APIs should be done by treating pylibcudf as a pure Python API).

[lithomas1]

Updated.

Followup:
Is there still a plan for a Cython API to pylibcudf then?
(or are the pxd's for internal pylibcudf use only)

[vyasr]

Good question. I still want the Cython API, but it's a lower priority. The Cython API will probably end up used in specific parts of cudf internals where we might actually see performance benefits, but in general I expect the bulk of usage to be of the Python API. The exceptions I foresee are cases like groupby or joins where generating many groupby/agg objects from cuDF can be accelerated using the pylibcudf Cython API.

[wence-]

Thanks!

[lithomas1]

I need to update the tests to swap the order of result and expected.

EDIT: Done

[wence-]

Thanks!

Issues addressed

[wence-]

/merge