[DOC] cudf.read_csv and internal ioutils should indicate how **kwargs are used.

[bdice]

Report incorrect documentation

Location of incorrect documentation
https://docs.rapids.ai/api/cudf/nightly/api_docs/api/cudf.read_csv.html#cudf.read_csv

Describe the problems or issues found in the documentation
The cudf.read_csv function accepts **kwargs but it does not indicate how they are used. We should avoid accepting arbitrary keyword arguments because it makes it difficult for users to recognize when unsupported keywords are passed. For example, this silently ignores the user's intention (which might be to use usecols and dtype instead of cols and dtypes):

data = cudf.read_csv(data_file, cols=cols, dtypes=dtypes)[col]

These **kwargs are passed on in a couple places but I'm not familiar with their intended use:

• cudf/python/cudf/cudf/utils/ioutils.py

  Line 1145 in 4539e5e

  def ensure_single_filepath_or_buffer(path_or_data, **kwargs):

• cudf/python/cudf/cudf/utils/ioutils.py

  Line 1331 in 4539e5e

  **kwargs,

Suggested fix for documentation
Investigate read_csv and related utility functions to determine how **kwargs are used, and document them accordingly.

If possible, I would prefer to remove **kwargs from the I/O functions in favor of named keyword(s) that can serve the same purpose.

Tagging @rjzamora @ayushdg who may have insight from editing this code in the past.

[ayushdg]

Thanks for the ping @bdice. iirc the origin for kwargs was to allow users to pass in the storage_options kwarg for filesystem specific options (for eg the s3 key or gcs token) while reading data from remote filesystems. At the time this could not be an explicit argument in cudf apis since the goal was to match Pandas API which did not support this at the time.

However since then Pandas has also adopted fsspec, the same library used by cudf and dask for handling different filesystems and as a result does expose storage_options (more details in #6916).
IMO we should be good to remove kwargs and expose storage_options for the relevant io api's that expose the same param as well.

[rjzamora]

IMO we should be good to remove kwargs and expose storage_options for the relevant io api's that expose the same param as well.

Right - We can remove kwargs if we expose storage_options and open_file_options (used for remote-storage optimizations) in read_csv. In an ideal world, the information in open_file_options could be included in storage_options, but this isn't quite possible yet.

[github-actions]

This issue has been labeled inactive-30d due to no recent activity in the past 30 days. Please close this issue if no further response or action is needed. Otherwise, please respond with a comment indicating any updates or changes to the original issue and/or confirm this issue still needs to be addressed. This issue will be labeled inactive-90d if there is no activity in the next 60 days.

[github-actions]

This issue has been labeled inactive-90d due to no recent activity in the past 90 days. Please close this issue if no further response or action is needed. Otherwise, please respond with a comment indicating any updates or changes to the original issue and/or confirm this issue still needs to be addressed.

[galipremsagar]

Resolved by #11762