refactor(rust, python): Remove old cut/qcut

[magarick]

As discussed, this removes the old cut and qcut. It also changes the default behavior to return Series instead of DataFrames but lets the new functions return "old style" data as well. Finally, it makes NaNs bin to null instead of accidentally putting them in a bin.

One thing to note is that the new algorithm isn't parallel yet but it could (and should) be. I tried a few things but couldn't get it to work.

[ritchie46]

It also changes the default behavior to return Series instead of DataFrames but lets the new functions return "old style" data as well.

That would be a breaking change. It should return a DataFrame for the Series.cut/ Series.qcut variant.

[magarick]

It also changes the default behavior to return Series instead of DataFrames but lets the new functions return "old style" data as well.

That would be a breaking change. It should return a DataFrame for the Series.cut/ Series.qcut variant.

For python I could change the default back but honestly returning a data frame wasn't the right thing to do in the first place. On the rust side though I'm not sure how feasible it is since the underlying functions now return a series. Do you want replacement cut and cut functions added back to the "Algo" crate that just mimic the old format and arguments (and possibly warn people not to use them)?

[ritchie46]

I am talking on the python side. On the rust side it is fine, we only need an expression on the rust side.

For python I could change the default back but honestly returning a data frame wasn't the right thing to do in the first place.

I think a DataFrame is easier to grok than a struct. Conversion between the two is free anyway. So I think for a Series it is a good default. For an expression it isn't possible and the struct is good.

[magarick]

I am talking on the python side. On the rust side it is fine, we only need an expression on the rust side.

For python I could change the default back but honestly returning a data frame wasn't the right thing to do in the first place.

I think a DataFrame is easier to grok than a struct. Conversion between the two is free anyway. So I think for a Series it is a good default. For an expression it isn't possible and the struct is good.

For the series it does convert back to a DataFrame and never returns a struct. Only a categorical series or DF. I think changing the default is ok though since the function's documentation always said it was experimental and subject to change. The new default is more likely what people are looking for too.

[ritchie46]

Ok, no strong opinion on my part. Going in, thanks!

[gkns1]

@ritchie46 You were right about this PR being a breaking change.
Even if cut was experimental, In the future could changes like that be marked as breaking or highlighted in release notes?
Polars is awesome, but patches with breaking changes make it hard to adopt and keep up with new releases. Thanks!

[magarick]

@gkns1 It should be able to work almost identically to the old version if you want it to. Is there something in particular you need?

[gkns1]

It's just the fact that it now returns a series by default instead of dataframe. It's an easy fix, but I had to first find out what happened when a build was failing. Failing builds is a risk I'm willing to take by using very new software, but a flag/highlight in release notes would help find it much faster.

[ritchie46]

It's just the fact that it now returns a series by default instead of dataframe. It's an easy fix, but I had to first find out what happened when a build was failing. Failing builds is a risk I'm willing to take by using very new software, but a flag/highlight in release notes would help find it much faster.

Yes, you are right. Sorry about that. Somehow forgot the breaking flag.

[lidh15]

May I have a question that where cut/qcut are now?
previously we use use polars_algo::{cut, qcut}; and now they were removed, what should I do after upgrading polars to 0.31.1?