Enforce deprecations in 23.10

[galipremsagar]

Description

This PR enforces previously deprecated code until 23.08 in 23.10. This PR removes strings_to_categorical parameter support in read_parquet.

Checklist

• I am familiar with the Contributing Guidelines.
• New or existing tests cover these changes.
• The documentation is up to date with these changes.

[rjzamora]

Thanks @galipremsagar - I'm on board with this deprecation/removal. However, I'd like to get some clarification on the new "best practice".

[rjzamora]

I know that some RecSys-based users have historically relied on strings_to_categorical=True to deal with the fact that their ML/DL model would often require them to convert string data to numerical data (but they needed to preserve information in the original string data on disk, and couldn't work with a fully-numerical Parquet file).

What is the new "best practice" for these users? Should we suggest something like df["A"] = df["A"].hash_values()? Was strings_to_categorical=True previously doing something clever to avoid reading the entire string column into GPU memory?

[rjzamora]

cc @EvenOldridge (in case you had further input here)

[galipremsagar]

Was strings_to_categorical=True previously doing something clever to avoid reading the entire string column into GPU memory?

@vuule would be the right one to know if there was any such thing happening.

What is the new "best practice" for these users? Should we suggest something like df["A"] = df["A"].hash_values()?

If someone was relying on this, yes hash_values would be the consistent alternative. hash_values by itself is consistent, but won't yield similar integers as to legacy strings_to_categorical=True behavior.

[vuule]

Was strings_to_categorical=True previously doing something clever to avoid reading the entire string column into GPU memory?

We don't create a string column with this option - string data in the file is hashed in the kernel and we just return an int32 column. So, yeah, something like df["A"] = df["A"].hash_values() is likely to have higher memory use at times.

[rjzamora]

We don't create a string column with this option - string data in the file is hashed in the kernel and we just return an int32 column. So, yeah, something like df["A"] = df["A"].hash_values() is likely to have higher memory use at times.

That's too bad, but certainly makes sense. I don't think anyone was actually using strings_to_categorical, but I get the sense that people will be starting to ask for exactly this functionality in the near future :/

[vuule]

If there are practical use cases, I wouldn't mind the feature as a "read strings as int" conversion support.

[rjzamora]

Thanks @vuule, that's good to know. I'll raise an issue if/when I have a practical use case to point to (otherwise this is low priority).

[galipremsagar]

/merge

Prem thinks there's a GH UI bug. Re-approving.

[bdice]

Re-approving.

[wence-]

I'll just note that by removing the cython wrapping of the parquet options builder path there's now no way to call the libcudf functionality from Python. This might mean that there's no longer a need for the libcudf code at all?

[galipremsagar]

I'll just note that by removing the cython wrapping of the parquet options builder path there's now no way to call the libcudf functionality from Python. This might mean that there's no longer a need for the libcudf code at all?

Yup, @vuule would likely be removing it from libcudf code aswell.