[DOC] can I rely on Series. _from_column ?

[martindurant]

Report needed documentation

#16454 stopped the ability to create Series from column objects, and introduces the _from_column class method to achieve the same. awkward and akimbo-cudf were using this code path. Can we call the new class method and expect it to be supported?

@jakirkham suggested posting this issue.

awkward PR: scikit-hep/awkward#3309

akimbo PR: intake/akimbo#88

[bdice]

Private methods (those starting with an underscore) are not considered to be part of the stable/public API. In the future, we will provide public pylibcudf APIs as a means to handle lower-level interoperation between libcudf and cuDF's Python layer. We have a few open issues related to this request:

• [FEA] Add public interop functions between pylibcudf and cudf classic #17191 -- needed for public APIs converting between cuDF Series and pylibcudf Column objects
• [FEA] Support more flexible construction of nested columns in pylibcudf #17192 -- needed to construct lists columns with public factories

We are hoping to have these features in the public API for the 25.02 release.

[martindurant]

Please keep me updated - I hope we will not have to change too much. To be sure: this functionality was available without a "_" method in the previous release.

[vyasr]

For the moment if you need to use that method, please continue to do so. Everything related to cuDF Column objects falls into the unfortunate bucket of parts of cuDF that were intended to be internal but were public and useful enough that various libraries started to use them. We unfortunately do not yet have the public APIs in place to replace existing functionality because we do not yet have a full scope of what projects have been relying on that we did not intend them to. #17317 is where we will be discussing the next steps, so please feel free to comment there and let us know what are all the functions that you are accustomed to performing directly on cuDF Column objects and we will take that into account as we work on our internal redesign. My expectation is that pylibcudf will satisfy many if not most of the current needs, but I also anticipate that there will continue to be some use cases where users need to interact directly with cuDF Column objects (such as for introducing custom dtypes). At present we have put a lot more thought into pylibcudf's API than how exactly cuDF internals will look once pylibcudf is ready, but that will be changing in the next 2-4 months.