-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
date_ranges
: ComputeError and different behaviour than int_ranges
#11892
Comments
Yes it should, this is a bug.
I'm not so sure about this one though... |
Maybe a strict=False mode. Given that people might want to use this in a when/then/otherwise, I like the idea of preventing ignoring the error like we have with cast As a work around OP could do something like:
|
I think both are reasonable options but it currently is inconsistent
I personally prefer the |
Hm yeah, I think I agree... @MarcoGorelli what are your thoughts on this one? |
Yup, this is what I'd expect; matches both Python and Rust behaviour with ranges (where start > end), so would be consistent with both of our main underlying languages/syntaxes. I don't think anyone would be surprised by it? 👍 |
Sounds reasonable - just one thing to note, I think that for |
Seems correct to me, that's how it is now. |
Checks
I have checked that this issue has not already been reported.
I have confirmed this bug exists on the latest version of Polars.
Reproducible example
Log output
No response
Issue description
ComputeError:
start
andend
must have the same length"manually" specifying start/end should work but is does not
ComputeError:
end
must be equal to or greater thanstart
int_ranges
behaves different here. I think this should be consistent and using the int version. If end is smaller than start the range should be empty.Expected behavior
examples above should all work.
int_ranges
)int_ranges
)Installed versions
The text was updated successfully, but these errors were encountered: