feat!: rewrite pl$date_range() and add pl$datetime_range()

[eitsupi]

No description provided.

[eitsupi]

@etiennebacher Please review.

[etiennebacher]

Thanks, I have a question on whether passing datetimes in pl$date_range() should be deprecated (as is in this PR) or removed.

[etiennebacher]

Can't we inherit that from another part of the docs? I think there's the same list elsewhere

[eitsupi]

Can't we inherit that from another part of the docs? I think there's the same list elsewhere

Sorry, but I don't understand what you want to say. This section is inherited by pl_datetime_range and there are no duplicates.
I don't think refactoring other functions' documentation is in the scope of this PR. (I don't want to make this PR huge anymore)

[etiennebacher]

My point was that Expr_rolling has almost the same thing in @details (but the first sentence is different so we can't just inherit it here)

[eitsupi]

Ok, I will update the docs in #958

[eitsupi]

Thanks, I have a question on whether passing datetimes in pl$date_range() should be deprecated (as is in this PR) or removed.

My understanding is that passing a Datetime is not deprecated, but rather that a breaking change will be introduced in the future that will return a Date even if a Datetime is passed.

Python has built-in logic to issue a warning when a Datetime is returned, but I haven't implemented it at the moment because it's cumbersome to copy.
https://github.com/pola-rs/polars/blob/103bb664b59acc4a9c48771f65ecc8f25b3bd303/py-polars/polars/functions/range/date_range.py#L335-L356

[etiennebacher]

My understanding is that passing a Datetime is not deprecated, but rather that a breaking change will be introduced in the future that will return a Date even if a Datetime is passed.

Returning a Datetime in pl$date_range() has been deprecated since py-polars 0.19.3, I think we can safely assume it's gonna be removed in 1.0.0. This PR is a big refactor of pl$date_range() with several other breaks, so to me we should use this opportunity to implement this breaking change. Also, deprecating without warning doesn't help users, so if we end up deprecating this usage there should be a message.

[eitsupi]

We can't make this breaking change here because no changes have been introduced to the upstream Rust side.

[eitsupi]

I have added warnings.

[eitsupi]

Although I wrote that breaking changes cannot be made now, the time_unit and time_zone arguments can be removed.

However, even if we do that, we can't delete the the warnings, so I think it's fine as is now.

[etiennebacher]

Thanks!