chore: parse strings as columns names at narwhals-level

[MarcoGorelli]

closes #1390 (completely by accident 😳 😄 )

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

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

Related issues

• Related issue #<issue number>
• Closes #<issue number>

Checklist

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

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

[FBruzzesi]

Thanks @MarcoGorelli that's quite a refactor!

Not a real concern but maybe something to think about is:

• The asymmetry in some method specs, between Narwhals and Compliant objects
• The expected simple_select method (just needs documentation I guess)
• Are we adding any extra overhead?

[FBruzzesi]

Is calling .columns ok for the lazy case? doesn't polars raise a warning?

[MarcoGorelli]

true, but it's crashing at this point anyway, might as well let it warn

[FBruzzesi]

Interesting change here, I am gladly surprised that everything plays out!

[MarcoGorelli]

thanks for your review!

The asymmetry in some method specs, between Narwhals and Compliant objects. The expected simple_select method (just needs documentation I guess)

It's true that there's some asymmetry, but I think that's OK - in my head, the separation is:

• compliant level: strict and minimal
• narwhals (user-facing) level: more ergonomic

Are we adding any extra overhead?

From tests I've done locally it doesn't look like it. Theoretically i'd expect it to be slightly lower, if we're just doing a single isinstance(expr, str) check upfront as opposed to repeatedly when parsing expressions at the compliant level

[FBruzzesi]

Amazing stuff (as usual!)🚀

[MarcoGorelli]

😄 thanks for your review, much appreciated!