Allow to set the style kwargs only in set_style and not in plot

[glemaitre]

While working on #1805, it looks like there a possibility to hand up with several kwargs style. Let's provide an example:

    def plot(
        self,
        *,
        x: str | None = None,
        y: str | None = None,
        hue: str | None = None,
        kind: Literal["dist", "corr"] = "dist",
        top_k_categories: int = 20,
        scatterplot_kwargs: dict[str, Any] | None = None,
        stripplot_kwargs: dict[str, Any] | None = None,
        boxplot_kwargs: dict[str, Any] | None = None,
        heatmap_kwargs: dict[str, Any] | None = None,
        histplot_kwargs: dict[str, Any] | None = None,
    ) -> None:

Switch kind or providing x, y, or hue will choose different type of visual representation and we need to dispatch which part to tweak. Currently, we have two ways to tweak:

display = report.data.analyze()
display.plot(x="xxx", histplot_kwargs=dict(color="tab:orange"))

or

display = report.data.analyze()
# example when we "persist" the style
display.set_style(histplot_kwargs=dict(color="tab:orange"))
display.plot(x="xxx")
# it can also be used in one liner
display.set_style(histplot_kwargs=dict(color="tab:orange")).plot(x="xxx")

The set_style was introduced to be able to persist the style across call to display at first.

Now, I'm wondering if we should not limit the API and allow only to call set_style to set the kwargs. The reasoning behind:

• it is not longer to write
• user benefit from the persisted style by default
• it bring clarity in the plot method because we reduce the number of parameters to only the element that will define what is shows on the plot
• we do not really introduce a new API here just give one way to do something

In short the API for the above case would become:

    def plot(
        self,
        *,
        x: str | None = None,
        y: str | None = None,
        hue: str | None = None,
        kind: Literal["dist", "corr"] = "dist",
        top_k_categories: int = 20,
    ) -> None:

and

    def set_style(
        self,
        *,
        scatterplot_kwargs: dict[str, Any] | None = None,
        stripplot_kwargs: dict[str, Any] | None = None,
        boxplot_kwargs: dict[str, Any] | None = None,
        heatmap_kwargs: dict[str, Any] | None = None,
        histplot_kwargs: dict[str, Any] | None = None,
    ) -> self:

[thomass-dev]

Related issue: currently, user can't customize displays that are persisted in the skore-hub-project, because he doesn't have control over how each metric is called.

For instance, user can't customize the Precision Recall that will be displayed on the hub for a given report. Under the hood, it's like

display = report.metrics.precision_recall()
display.plot()

project.put([...], display.figure_)

Can't we go a bit further of your proposition and add also styling at the function level, accessor level, or even at the report level?
For instance report.data.analyze.set_style, report.data.set_style or report.set_style, that way each call inherits from this configuration?

[glemaitre]

I would consider it another issue but one day we should address.

I kind of agree with you that currently, because of the way that we persist thing at the level of the report, we would need a set_style at the level of the accessor or report. However, the issue in terms of API is that set_style applied to an accessor as we currently do will be too messy because you have no idea to which display the styling is applied.

So we should think about this API. What come directly in mind is:

report.data.set_style(display="analyze", histplot_kwargs=dict(color="tab:orange"))
project.put("toto", report)  # report will recover the style set earlier

Most probably, it will be one of those features that might be a bit complex to use but that is really an advanced case to tweak details, so it might be fine.

[thomass-dev]

I would consider it another issue but one day we should address.

👍🏻

However, the issue in terms of API is that set_style applied to an accessor as we currently do will be too messy because you have no idea to which display the styling is applied.

report.data.analyze.set_style can avoid that!

[glemaitre]

report.data.analyze.set_style can avoid that!

The problem is that analyze is a Python function already. Making a callable class with a class method set_style might be really complex to implement instead of having a pure method with a display argument.

But I would need to see the implementation to really witness the complexity.

[MarieSacksick]

I like the solution set_style best because it alleviates the number of parameters to the plot function, and make it easier to read.
I also like the fact that there is one way to do one thing.