`cudf-polars` string/numeric casting
Depends on https://github.com/rapidsai/cudf/pull/16991 Part of https://github.com/rapidsai/cudf/issues/17060
Implements cross casting from string <-> numeric types in cudf-polars
@wence- in this case polars is testing for a specific exception when a string can't be cast to an integer. We're able to raise an exception in the right place on the cudf-polars side, but because of the way we wrap it in a polars.exceptions.ComputeError we assert False in the end.
FAILED py-polars/tests/unit/sql/test_cast.py::test_cast_errors[values5-values::int4-conversion from `str` to `i32` failed] - polars.exceptions.ComputeError: InvalidOperationError: Conversion from `str` failed.
The easiest thing would be to add this to the list of expected failures. That said, have we ever explored the idea of propagating the original exception back to the user in the case of runtime errors?
@wence- in this case polars is testing for a specific exception when a string can't be cast to an integer. We're able to raise an exception in the right place on the
cudf-polarsside, but because of the way we wrap it in apolars.exceptions.ComputeErrorwe assert False in the end.FAILED py-polars/tests/unit/sql/test_cast.py::test_cast_errors[values5-values::int4-conversion from `str` to `i32` failed] - polars.exceptions.ComputeError: InvalidOperationError: Conversion from `str` failed.The easiest thing would be to add this to the list of expected failures. That said, have we ever explored the idea of propagating the original exception back to the user in the case of runtime errors?
I've thought about it, but I think it's fiddly because this execution happens inside polars rust, which doesn't know about python exception types, I think.
Can you open an issue/feature in polars to discuss this please?
Any idea why tests are failing here?
Thanks Brandon, happy with the current state.
Can you please write up a bit more detail in #17244 about the different casting modes, what cudf-polars currently does, and the routes to supporting them.
IIUC this PR is ready to merge and @brandon-b-miller just needs to add a bit more info to #17244, right?
/merge