[Enh]: Support `int_range`

[dangotbanned]

Related

• [Enh]: Allow LazyFrame.with_row_index(..., order_by=...) #2307 (comment)
• [Enh]: Allow LazyFrame.with_row_index(..., order_by=...) #2307 (comment)
• feat: Add order_by option in with_row_index method #2683

Description

polars.int_range was considered in (#2307) but ultimately wasn't the right fit.

I still think it's got a lot of utility on it's own and could be a model for a future date_range.

Really anywhere a package might be using range or np.arange - we'd be able to offer an alternative that:

1. Is performant
2. Doesn't depend on anything beyond backend
   i. Similar to other entry points we have like 1, 2
3. Gives you direct access to the rest of the narwhals API
   i. nw.int_range(..., eager=True) -> nw.Series
   ii. nw.int_range(..., eager=False) -> nw.Expr

[dangotbanned]

Update

For pyarrow>=21 we can use pa.arange without introducing a numpy dependency

• GH-46771: [Python][C++] Implement pa.arange function to generate array sequences apache/arrow#46778

Currently usage is in (code search):

ArrowDataFrame

• .with_row_index(name, order_by=None)
  • ArrowExpr.over(order_by=...)
• .is_unique
  • ArrowSeries.is_unique
• .unique
• .sample

ArrowSeries

• .sample
• .fill_null(None, strategy, None)
  • .rolling_var
  • .rolling_sum
  • .rolling_mean
• .is_first_distinct
• .is_last_distinct
• .to_dummies
• .hist

[dangotbanned]

(#2895) is targeting eager-only support.

For lazy backends, we'll need to think more about .list as exploding/unnesting is how the range becomes a column

[FBruzzesi]

Another pain point, even for the eager case, would be to support int_range within a over context 🤔
I think it's ok to move one step at the time

[MarcoGorelli]

For lazy backends, we'll need to think more about .list as exploding/unnesting is how the range becomes a column

not sure about this - we'd just be unnesting internally, so it's not like the user would need to call any .list function themselves