MNT Narwhals in utils._input_validations - #1533

This is an interesing one.

To reproduce:

import pandas as pd
from sklearn.utils.validation import check_array

df = pd.DataFrame({"alpha": ["a", "a", "b"], "beta": [1, 2, 1]})
df = df.convert_dtypes(dtype_backend="pyarrow")
# or
# df = df.convert_dtypes(dtype_backend="numpy_nullable")

check_array(df, dtype=None)

Did you encounter this already @FBruzzesi? Maybe in scikit-lego?

I believe scikit-lego was very early days of Narwhals, and we are not testing with different pandas dtype_backend 🙈

The root cause is that _validate_and_reformat_input routes X through check_array, which materializes to NumPy — so a string[pyarrow] (or nullable) column can't be cast and it blows up. It's not really fixable as long as validation goes through check_array; the proper fix is to validate via narwhals instead, which is out of scope here.

After merging main, the shared test/conftest.py now also parametrizes over the nullable/pyarrow dtype backends (other modules rely on them). To keep that coverage without breaking the utils tests, I added a local test/unit/utils/conftest.py that narrows constructor to the backends check_array actually supports (pandas, polars, native pyarrow table). I can open a follow-up issue to track proper support for pandas extension-dtype backends in input validation. Wdyt?

I had to add this in places were narwhals is not yet supported. Since we import polars in the tests, it becomes the default backend.

This is fine as a temporary workaround and the TODO makes the intent clear, so no objection to keeping it for this PR. The only reason it's needed is the .values calls right after, which are pandas-only. If we swap those for np.asarray(y_true) / np.asarray(sensitive_features) (works on both pandas and polars Series), the forced backend goes away entirely. Happy to make that small change here or leave it for the follow-up that removes these temporary shims — your call.

is everyone happy about this priority?

One thing to weigh: this default only kicks in when inputs aren't dataframes/series (e.g. NumPy) and no explicit backend is passed — it decides what type comes back out. With polars first, a user passing NumPy arrays gets polars Series back whenever polars is installed, which is a behavior shift for our historically pandas-centric users (and it's also what makes the default_backend=PANDAS workaround in the other thread necessary in tests).

My inclination is pandas > polars > pyarrow for backward compatibility, unless we explicitly want to push polars as the default output. Since it's a user-facing policy call, this feels like a good one to confirm with @fairlearn/fairlearn-maintainers @FBruzzesi, thoughts? I am fine with it either way.