Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Removing the
FrameProxyObject
workaround (#751)
Adding testing of cudf dataframe copy, which fails prior to rapidsai/cudf#9397 #### UPDATE: This PR now handles the jit-unspill failures we have been seeing with cudf v21.12. Some background, when we introduced `ProxyObject`, cudf was using `cudf._lib.table.Table` as the base class for all frame-like objects (dataframes, series, etc). `Table` was implemented in cython so our proxy object had to derive from `Table` in order to support cython functions. The result was to use the class `FrameProxyObject` as a workaround: ```python # In order to support the cuDF API implemented in Cython, we inherit from # `cudf._lib.table.Table`, which is the base class of Index, Series, and # Dataframes in cuDF. # Notice, the order of base classes matters. Since ProxyObject is the first # base class, ProxyObject.__init__() is called on creation, which doesn't # define the Table._data and Table._index attributes. Thus, accessing # FrameProxyObject._data and FrameProxyObject._index is pass-through to # ProxyObejct.__getattr__(), which is what we want. class FrameProxyObject(ProxyObject, cudf._lib.table.Table): pass ``` Now that cudf uses `Frame`, a pure Python class, we don't need this workaround anymore. In fact, using `FrameProxyObject` triggers some infinite recursion errors when used together with v21.12+ cc. @randerzander Authors: - Mads R. B. Kristensen (https://github.com/madsbk) Approvers: - Peter Andreas Entschev (https://github.com/pentschev) URL: #751
- Loading branch information