Let `TableReport` accept `skrub` expressions as input

[ogrisel]

Problem Description

At the moment, the following code snippet:

import polars as pl
import skrub

skrub.TableReport(skrub.var("df", pl.DataFrame({"a": range(3)})))

raises NotImplementedError while the usual:

skrub.TableReport(pl.DataFrame({"a": range(3)}))

works as expected which can be confusing.

Feature Description

I agree that any skrub expression wrapping a dataframe naturally embeds the TableReport view as part of their HTML representation for Jupyter notebook when they end up in the output of a notebook cell.

However, I suspect that some users might want to use TableReport programmatically outside of any notebook and the above NotImplementedError exception can be confusing.

Alternative Solutions

No response

Additional Context

No response

[rcap107]

Writing

skrub.TableReport(skrub.var("df", pl.DataFrame({"a": range(3)})).skb.eval())

returns the proper report.

We could either change the error message to suggest the .skb.eval(), or maybe add a parameter to the TableReport that forces the evaluation if it is passed an expression.

I'm leaning towards having a first PR that adds the error message, and later a PR to add full support

[Vincent-Maladiere]

We could either change the error message to suggest the .skb.eval()

I'm +1 for a clear error message

[GaelVaroquaux]

We could either change the error message to suggest the .skb.eval() I'm +1 for a clear error message

I agree that I would prefer an error message than having the TableReport transparently accepting expressions. The reason is that I think that it is important that users understand that they are manipulating different type of objects. The counter argument could be that we should make it as simple as possible to replace normal df code by expression. I'm happy being convinced of this if other people (eg @ogrisel) think that this is the way to go.

[ogrisel]

Improving the error message would already be helpful.

[jeromedockes]

With the recently-merged #1416 the error is now

TypeError: Operation not supported on this object. Expecting a Pandas or Polars object, but got an object of type <class 'skrub._expressions._expressions.Expr'>.

which is already much better than NotImplementedError. Maybe the check introduced by #1416 should special-case expressions with a tailored message so that we get a good message whenever an expression reaches a "dispatched" function, which might happen in a few other cases

[jeromedockes]

I agree not transparently evaluating the expression will help users understand where they can and cannot pass an expression. another reason is when subsampling is used, we would decide if we show the subsampled preview or the full result, and if we choose the latter the evaluation could trigger errors or long computations not related to the tablereport which could also be surprising

[Vincent-Maladiere]

Maybe the check introduced by #1416 should special-case expressions with a tailored message so that we get a good message whenever an expression reaches a "dispatched" function, which might happen in a few other cases

I like this idea!

[GaelVaroquaux]

Maybe the check introduced by [2]#1416 should special-case expressions with a tailored message so that we get a good message whenever an expression reaches a "dispatched" function, which might happen in a few other cases I like this idea!

+1!

[ogrisel]

I agree not transparently evaluating the expression will help users understand where they can and cannot pass an expression. another reason is when subsampling is used, we would decide if we show the subsampled preview or the full result [...]

Indeed. Ideally the message could hint as the user at calling either expr.skb.eval() or expr.skb.preview() depending on what they want to achieve in this case.

[rcap107]

From IRL discussion:

Good to have, but should not be a blocker for 0.6.0. We can release a fix in 0.6.1

[jeromedockes]

closing thanks to #1607