feat: Add `{Expr,Series}.any_value`

[FBruzzesi]

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

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

Related issues

• Closes #3298

Checklist

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

[MarcoGorelli]

thanks!

some initial thoughts:

• I think the function just needs to not make any guarantees about order, I don't think we need to intentionally add randomness, just taking first for eager backends should be enough (it's likely more performant anyway, right?)
• i'm slightly concerned that sql ignores nulls in this function, but we're suggesting to not to. if polars were to add this method, would they ignore nulls or not? perhaps we could have a mandatory ignore_nulls keyword argument, similar to how we have it in any_horizontal?

[FBruzzesi]

Thanks @MarcoGorelli

• I think the function just needs to not make any guarantees about order, I don't think we need to intentionally add randomness, just taking first for eager backends should be enough (it's likely more performant anyway, right?)

Wouldn't using first actually make a lot of guarantees on order for eager backends?

• i'm slightly concerned that sql ignores nulls in this function, but we're suggesting to not to. if polars were to add this method, would they ignore nulls or not? perhaps we could have a mandatory ignore_nulls keyword argument, similar to how we have it in any_horizontal?

Sure I will add such option 🙏🏼

[MarcoGorelli]

Wouldn't using first actually make a lot of guarantees on order for eager backends?

Sure, but we don't guarantee it - an in, it happens to return the first value, but it's not guaranteed (and the name any_value strongly implies there's nothing guaranteed)

Polars does something similar in joins - in the eager case it may happen to return rows in the same order when it's more efficient to do so, but it's not guaranteed (and it's documented that it's not guaranteed)

[MarcoGorelli]

thanks for updating, will try to review next week

[FBruzzesi]

@MarcoGorelli just to make sure we align before going on a tangent. We briefly touched the possibility of explicitly marking this feature as unstable as it's outside of polars API. Next steps would be:

• Simple warning in the main namespace docstrings
• Code/runtime warning in the stable namespaces OR even raise an error in the stable namespaces

Let me know what your thoughts are :)

---

Update: Ok I pushed a proposal in https://github.com/narwhals-dev/narwhals/pull/3315/commits/e8d44f6033cdfcdab477e78ab41b804009d7d98f