[FEA] Use List of Columns instead of Frames in Cython API

[isVoid]

Following the removal of Table class #9315, and a pilot study of changing several cython APIs into using list of columns #9558, we want to extend the previous effort and use lists of columns to replace usage of Frame with list of columns. The main arguments for this change are:

1. Libcudf's table_view is essentially a thin wrapper of vector<column_view>, this match with list of column concept.
2. In the vision by data consortium API, dataframes does not have a column name.
3. From developer's perspective, we want to rely on simpler data structure on cython layer for easy debugging.

This is a meta issue that tracks the list of candidate APIs that awaits to be changed and the refactor progress.

The following list is compiled by searching \(\n?.*table_view.*(\n|\)) in the cpp code base and find their corresponding wrapper in cython.

• Copying.pyx:
  • Scatter: should we expand the cython interface to support multi column scatter?
  • table_empty_like
  • table_slice
  • table_split
  • boolean_mask_scatter_table: see [FEA] Use libcudf's boolean mask scattering for setitem #8667.
  • sample
• filling.pyx:
  • repeat
• groupby.pyx:
  • groupby.__cinit__
  • groupby.groups
  • groupby.shift
  • groupby.replace_nulls
• hash.pyx:
  • hash
• interop.pyx:
  • to_dlpack
• join.pyx:
  • join/semi_join: lhs, rhs
• merge.pyx:
  • merge_sorted
• partitioning.pyx:
  • partition
• quantile.pyx:
  • quantiles
• reshape.pyx:
  • interleave_columns
  • tile
• search.pyx:
  • search_sorted
• sort.pyx:
  • is_sorted
  • order_by
  • digitize
  • rank_columns
• transform.pyx:
  • table_encode
• transpose.pyx:
  • transpose
• csv.pyx:
  • write_csv: note index argument
• orc.pyx:
  • write_orc
• parquet.pyx:
  • write_parquet
• lists.pyx:
  • explode_outer
  • concatenate_rows
• string/combine.pyx:
  • concatenate

Second step from this is to remove utils.table_view_from_table completely.

[GregoryKimball]

@isVoid Should we close this, make a new issue for the IO files, and label it "good first issue"?

[isVoid]

I would still like to keep tracking in this issue. Especially the I/O files refactors are the hardest among the cohorts. I don't think moving it to a separate issue will help lowering the barrier.

[vyasr]

I'm going to close this issue. With pylibcudf coming we are going to have to rethink the internals of cudf further. Ultimately the list of columns approach we took here is certainly going to be closer to the final end state, but it is no longer directly applicable to future design.