API: make hide_columns and hide_index have a consistent signature and function in Styler

[attack68]

This closes #41158 (which is an alternative PR for similar functionality)

Currently hide_index() and hide_columns(subset) have similar signatures but different operations. One hides the index whilst showing the data-rows, and the other hides data-columns whilst showing the column-headers row.

This PR

• adds the subset keyword to give: hide_index(subset=None).
• sets the default to hide_columns(subset=None).

When subset is None the function now operates to hide the entire index, or entire column headers row respectively.
When subset is not None it operates to selectively hide the given rows or columns respectively, keeping the index or column headers row.

We also add the show keyword to allow the method to operate inversely.

@jreback I think you will prefer this over the hide_values and hide_headers methods suggested in #41158 since this re-uses the existing methods with minimal changes but tries to align their consistency. It is also fully backwards compatible.

[attack68]

all that was changed here was to add if not self.hidden_colheads:, the other additions and removals in comparison window are misleading.

[jreback]

ok i undestand what you are doing, but this is still a very confusing api. we want to support

• hide index values themselves
• hide column values themselves
• hide particular columns

can you show me what you would write for these?

[attack68]

ok i undestand what you are doing, but this is still a very confusing api. we want to support

• hide index values themselves
• hide column values themselves
• hide particular columns

can you show me what you would write for these?

sure..

The mechanics seem to be in place to do this quite easily, it just needs steering on the best API implementation..

[jreback]

ok your example looks fine. I am confused by the show keyword then.

[attack68]

ok your example looks fine. I am confused by the show keyword then.

I removed the show option. Can always add it back later or do it in a different way

[jreback]

this is pretty confusing, why is this not just a list-like (of row labels)? e.g. similar to the argument for .dropna() for example

[attack68]

changed. pls review

[jreback]

same comment as above

[jreback]

now I wouldn't object to also allowing an IndexSlice here (in addition to a list-like of columns labels)

[attack68]

changed. pls review

[jreback]

can you show an example first that has a single level index.

[attack68]

added

[jreback]

can you change the impl to use the same nomenclature, e.g. hidden_index, hidden_columns (or similar)

[attack68]

Can you give your input to the suggestion below:

self.hide_index_: bool
self.hide_columns_: bool
self.hidden_indexes: Sequence[int]
self.hidden_columns: Sequence[int]

[attack68]

updated (used rows instead of indexes)

[jreback]

this is good, thanks @attack68 as a followup can you make sure that these methods are in the api ref & also we have sufficient docs in the notebook (the doc-strings are great obviously), but generally give an update in the notebook (its not of course necessary to add everything, but major things like this are good).

[jreback]

@meeseeksdev backport 1.3.x

[lumberbot-app]

Something went wrong ... Please have a look at my logs.

[Leonardofreua]

Hi @attack68. I'm working on issue #42674 and I found some doctests with expected results different from the real results (at least in my tests). See the examples below:

• hide_columns() (styles.py)

>>> midx = pd.MultiIndex.from_product([["x", "y"], ["a", "b", "c"]])
>>> df = pd.DataFrame(np.random.randn(6,6), index=midx, columns=midx)
>>> df.style.format("{:.1f}").hide_columns()
x   d    0.1    0.0    0.4    1.3    0.6   -1.4
    e    0.7    1.0    1.3    1.5   -0.0   -0.2
    f    1.4   -0.8    1.6   -0.2   -0.4   -0.3
y   d    0.4    1.0   -0.2   -0.8   -1.2    1.1
    e   -0.6    1.2    1.8    1.9    0.3    0.3
    f    0.8    0.5   -0.3    1.2    2.2   -0.8

As you can see below, the values d, e, and f don't appear in the result, because they were actually defined as a, b, and c. We can also see that x and y are aligned with b (second and fifth lines) and not with d (first and third lines):

Is there any reason these results are divergent?

Obs.: There are some other doctests in the same method after the one mentioned above, which present the same problem.