NVIDIA / NVIDIA/cudf

[FEA] Determine the best way to emulate keyword-only parameters in cpdef functions

Open
#15,136 2 comments 0 reactions 0 assignees View on GitHub
feature request pylibcudf Python
Dominant language
C++
Stars
9.8k
Forks
1.1k
Avg merge
3d 6m
Merged PRs (30d)
278

Description

**Is your feature request related to a problem? Please describe.**
Numerous pylibcudf APIs currently accept optional arguments because the corresponding libcudf APIs do. In C++, libcudf essentially forbids boolean parameters in favor of enums, which are at least self-documenting at the call site (unlike boolean parameters). However, if there are multiple such parameters the caller still has to remember the order of these parameters. In Python, we can solve this problem using keyword-only arguments, which forces the caller to access the parameters by name and therefore automatically protects against misuse by incorrect ordering. However, this solution does not work for `cdef` (and therefore `cpdef`) functions in Cython because such functions are effectively C functions and all arguments are therefore ultimately passed in order to these functions.

In a related vein, some libcudf APIs could be naturally exposed in pylibcudf using a single API with an additional parameter. For instance the stable variants on libcudf's sorting APIs would be very natural to expose in pylibcudf with an extra parameter `sort(..., stable : bool)`. However, this again runs into the same issue above where we would want to use a keyword-only argument but are stymied by the fact that this is unsupported.

**Describe the solution you'd like**
We should determine a standard practice for this kind of API in pylibcudf and document it in the developer guide. It is not clear to me what a good solution is though. One option would be to make these APIs `def` functions. That would allow using keyword-only arguments, but at the cost of not being able to take advantage of Cython call syntax with typed arguments in Cython contexts, which I'd like to avoid at this stage since at the moment the entire pylibcudf API supports usage in a pure Cython context and removing that is a broader conversation. We can revisit that option if we can't come up with any alternatives, though

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.