DEPR: Styler.where possible deprecation

[attack68]

closes #40124

Proposal to deprecate the method: Styler.where, since Styler.applymap and Styler.where are so similar in function, and return signatures, that it is almost confusing to have 2 methods for the same thing.

Note that Styler.where offers no advantage over applymap since internally it just restructures the callable and uses applymap itself:

def where(..):
    return self.applymap(lambda val: value if cond(val, **kwargs) else other, subset=subset)

[jreback]

i would actually deprecate .applymap, as its a non-vectorized version of .where (not that this matters for Styler generally).

ok can you separate out the bug fix and do the deprecation in a different PR? (where can discuss)

[attack68]

i would actually deprecate .applymap, as its a non-vectorized version of .where (not that this matters for Styler generally).

ok can you separate out the bug fix and do the deprecation in a different PR? (where can discuss)

my other PR #40845 fixes the bug. This one I left as the potential deprecation. Styler.where is not vectorized, it's effectively a one-liner invoking applymap.

[jreback]

cc @pandas-dev/pandas-core any thoughts here

[rhshadrach]

To use where in order to accomplish applymap seems unnatural:

df.where(cond=lambda _: True, some_style)

To use applymap to accomplish where seems natural:

df.applymap(lambda x: some_style if cond(x) else other_style)

[dsaxton]

To use where in order to accomplish applymap seems unnatural:

df.where(cond=lambda _: True, some_style)

To use applymap to accomplish where seems natural:

df.applymap(lambda x: some_style if cond(x) else other_style)

I think I agree with this. As a user I always find myself having to stop and think what where actually does, on the other hand methods like map, apply, and applymap are more obvious.

[jreback]

ok thanks, yeah no harm in deprecating