refactor(rust,python): refactor arange and add int_range/int_ranges

[stinodego]

Partially addresses #9019

Changes:

• Refactor arange to make use of the existing expression architecture
• Add int_range and int_ranges functions as alias for arange functionality.
  • While arange has some merit naming-wise (exists in numpy, for example), it's not a good name. What exactly is an 'array range'? We have time_range, date_range, let's be explicit and call this what it is: an int_range. We could add a float_range later, for example.
  • Splits out the vertical vs horizontal behaviours
• Add doc entry to Expressions / Functions

Future steps (not included here to keep diff somewhat small):

• Further refactor the functions, they're still messy.
• Support a dtype arg for int_range(s) on the Rust side to avoid materializing everything as Int64 first.
• Rename the feature?
• Deprecate arange?

Can we deprecate arange as a whole, or do we want to keep this function due to name familiarity? If we keep it, do we want to split out functionality into arange/aranges? I prefer getting rid of it entirely.

[MarcoGorelli]

Nice!

Is the idea to introduce int_range / int_ranges now, deprecate arange in favour of them, and then in 1.0 remove arange completely?

---

Just a suggestion testing-wise - perhaps it'd be good to test the schema in the lazy case, like how is done in the test_date_range_schema, / test_date_range_no_alias_schema_9037 tests?

[stinodego]

Is the idea to introduce int_range / int_ranges now, deprecate arange in favour of them, and then in 1.0 remove arange completely?

That's what I would propose. But I can imagine Ritchie might want to keep arange for its name familiarity. Either way, this PR keeps existing arange functionality, so we can do the deprecation later if we choose to.

Just a suggestion testing-wise - perhaps it'd be good to test the schema in the lazy case, like how is done in the test_date_range_schema, / test_date_range_no_alias_schema_9037 tests?

Thanks, I'll look into it!
EDIT: That actually caught a mistake, thanks @MarcoGorelli !

[ritchie46]

Looks good. I like that we moved the implementation properly to the new architecture.

On the naming of arange. I think we should keep it around as an alias to int_range. I believe the range in almost all programming language defaulted to integers. But given that we clarify the dtype for time and date, I understand the specific naming need.

[stinodego]

I think we should keep it around as an alias to int_range.

Sounds fair enough. Then I'll deprecate the part of arange that dispatches to int_ranges.

[Bidek56]

Is int_range and int_ranges functions only available in py-polars?
I am trying to upgrade nodejs-polars to rs-0.31.1 but I am getting:
error[E0425]: cannot find function 'int_ranges' in module 'dsl' Thx

[stinodego]

It should be available in Rust!

[Bidek56]

I see: #[cfg(feature = "range")] on top of the function, could that be causing a problem?

[stinodego]

Ah yes. The feature has been renamed from arange to range. So you must enable the correct feature for it to be available.

[Bidek56]

Adding: #[cfg(feature = "range")] decorator solves it. Thanks!!

[ritchie46]

Adding: #[cfg(feature = "range")] decorator solves it. Thanks!!

Are you sure? You should activate it on your cargo.toml. This decorator will only ensure your code is excluded from compilation until you activate that feature on your crate.

[Bidek56]

You are correct, #[cfg(feature = "range")] is not needed.

Adding these lines to Cargo.toml solves it, is this the best approach? Thx

[features]
default = ["range"]
range = ["polars-lazy/range"]

[ritchie46]

Yes.