[Enh]: support `Expr.map_elements`

[deepyaman]

We would like to learn about your use case. For example, if this feature is needed to adopt Narwhals in an open source project, could you please enter the link to it below?

Pandera supports element-wise checks.

• Polars: https://github.com/unionai-oss/pandera/blob/v0.29.0/pandera/backends/polars/checks.py#L48-L52
• Ibis: https://github.com/unionai-oss/pandera/blob/v0.29.0/pandera/backends/ibis/checks.py#L32-L35
• pandas: https://github.com/unionai-oss/pandera/blob/v0.29.0/pandera/backends/pandas/checks.py#L162-L163, https://github.com/unionai-oss/pandera/blob/v0.29.0/pandera/backends/pandas/checks.py#L167-L168

I'm currently working on a unifying Narwhals backend for Pandera (issue: unionai-oss/pandera#1894), and this is one of the gaps.

Please describe the purpose of the new feature or describe the problem to solve.

Provide a unifying abstraction to map a custom/user-defined function (UDF) to each element of a column.

Suggest a solution if possible.

No response

If you have tried alternatives, please describe them below.

No response

Additional information that may help us understand your needs.

There was some hesitation around adding map_elements without a clear use case (not surprising), but I think we have a valid need.

yay thanks @DeaMariaLeon !

@vincentarelbundock if custom f-strings are on polars roadmap anyway, then perhaps we can wait a bit longer before introducing map_elements to Narwhals, I'm a little hesitant about that one

Originally posted by @MarcoGorelli in #1226

[MarcoGorelli]

Thanks for the request!

How do ibis scalar python udfs work for the duckdb backend? If they materialise to a pyarrow table and then loop over elements then I'm afraid it's going to be a no, and i don't think such operations should ever be offered to lazy backends (it should be up to the user to intentionally materialise the data as and when needed)

[deepyaman]

Thanks for the request!

How do ibis scalar python udfs work for the duckdb backend? If they materialise to a pyarrow table and then loop over elements then I'm afraid it's going to be a no, and i don't think such operations should ever be offered to lazy backends (it should be up to the user to intentionally materialise the data as and when needed)

Ibis only supports Python UDFs when the backend supports them natively (you can see that many don't). For DuckDB, this happens through the create_function method.

[MarcoGorelli]

Ah thanks! Ok if at least duckdb (the default ibis backend) has a supported way to do this that doesn't involve materialisation upfront then maybe it's OK to consider this

I'm inclined to accept this then, so long as there's a warning in the docs that native expressions should always be preferred

[deepyaman]

I'm inclined to accept this then, so long as there's a warning in the docs that native expressions should always be preferred

Sure; even the Ibis docs stress that Python UDFs are likely to be slow. Similarly, we warn that they're slow in Pandera.