fix: modin dtype interoperability

[camriddell]

What type of PR is this? (check all applicable)

• 💾 Refactor
• ✨ Feature
• 🐛 Bug Fix
• 🔧 Optimization
• 📝 Documentation
• ✅ Test
• 🐳 Other

Related issues

• Semi-related PR feat: add is_nan expression & series method #1625

Checklist

• Code follows style guide (ruff)
• Tests added
• Documented the changes

If you have comments or can explain your changes, please do so below

Narwhals failed to preserve pyarrow backed datatypes with Modin-native backed DataFrames. This issue was first noticed in the aforementioned PR and subsequent MRE

# modin.pandas Series with pyarrow backed dtype
>>> import modin.pandas as mpd
>>> s = mpd.Series([1.0, None]).convert_dtypes(dtype_backend='pyarrow')
>>> s
0       1
1    <NA>
dtype: int64[pyarrow]

>>> import narwhals as nw
>>> ns = nw.from_native(s, series_only=True)
>>> ns.cast(nw.Float64).to_native() # loses pyarrow backend info
0    1.0
1    NaN
dtype: float64

With this PR, we appropriately preserve the dtype back-end

>>> import modin.pandas as mpd
>>> s = mpd.Series([1.0, None]).convert_dtypes(dtype_backend='pyarrow')
>>> s
0       1
1    <NA>
dtype: int64[pyarrow]

>>> import narwhals as nw
>>> ns = nw.from_native(s, series_only=True)
>>> ns.cast(nw.Float64).to_native()
0     1.0
1    <NA>
dtype: double[pyarrow]

An edge case was encountered in narwhals/_pandas_like/group_by.py where .get_group(...) would raise a KeyError if the passed key contained float("nan") (as it does in the testing suite). This is likely due to some copying/reconstruction of the nan object which fails to reproduce its original hash since its hash is compute against the object id.

[MarcoGorelli]

no better feeling than seeing a failing CI job and then reading

[XPASS(strict)] 

😎 well done! this is awesome

[MarcoGorelli]

😍

[MarcoGorelli]

legend, thanks so much @camriddell !

i've got something in progress for #1690 which should hopefully improve things for all these backends in tests