improves usability of style calls on axis=1 by automatically creating…
State: closed

- [ ] closes #xxxx
- [ ] tests added / passed
- [ ] passes `git diff upstream/master | flake8 --diff`
- [ ] whatsnew entry

… the IndexSlice same as it does for axis=1

```
df = pd.DataFrame(index = ['x', 'y', 'z'])
df['a'] = [1,2,3]
df['b'] = [4,5,6]
df['c'] = [7,8,9]
df

df.style.background_gradient(subset='x', axis=1)
```
# otherwise this throws some vague exception. seems like if you pass in

axis this should just work

`df.style.background_gradient(subset=pd.IndexSlice['x',], axis=1)` #same
as this


Labels:
name: Bug
name: Output-Formatting
description: __repr__ of pandas objects, to_string

Comments:
- add a test [here](https://github.com/pydata/pandas/blob/master/pandas/tests/formats/test_style.py#L546)
- add a whatsnew note

cc @TomAugspurger 

## [Current coverage](https://codecov.io/gh/pydata/pandas/pull/13273?src=pr) is **84.18%**

> Merging [#13273](https://codecov.io/gh/pydata/pandas/pull/13273?src=pr) into [master](https://codecov.io/gh/pydata/pandas/branch/master?src=pr) will decrease coverage by **<.01%**

``` diff
@@             master     #13273   diff @@
==========================================
  Files           138        138          
  Lines         50587      50584     -3   
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
- Hits          42593      42583    -10   
- Misses         7994       8001     +7   
  Partials          0          0          
```

> Powered by [Codecov](https://codecov.io?src=pr). Last updated by [b4e2d34...b88a4d7](https://codecov.io/gh/pydata/pandas/compare/b4e2d34edcbc404f6c90f76b67bcc5fe26f0945f...b88a4d7b85a858c49b6a352ee50dd78d3ffc697d)

Fixed most of the issues you highlighted except for passing self.data. While that probably makes sense it is outside the scope of this bug and I didnt feel like i undertstood the code base enough to comfortably make it

@perryvais thanks for the PR, sorry it took so long for me to respond.

Is this closing an issue? I'd like to get some more background / use-cases on this.

One thing that worries me is this would spread the slicing/subsetting logic over two keyword arguments. On master, the logic is
- scalars and lists are treated as column slices
- tuples (e.g. output of IndexSlice) are passed to `.loc`

I viewed the case of `subset=column` special enough to warrant the special case instead of just saying "everything goes through `self.data.loc`", so pass in a valid indexer there.

With this PR you would also have to take into account the `axis` argument anytime you make a slice. Is this second special case common enough to justify the extra complexity? Was I wrong in my initial guess about `axis=0` being more common than `axis=1`?

I don't think there is a preexisting issue but when i spoke to @jreback he believed it was a bug. I find the semantics of the styles to be a bit confusing but dont have a recommendation to clarify. The functionality is very helpful though. tried to create a gist but couldnt see styles but here is a screenshot. This PR gets the last line to behave like hte prior and consistent with the last line of the first cell.

![image](https://cloud.githubusercontent.com/assets/2051736/17102155/47d9f3ec-5246-11e6-9dad-5c155c257807.png)

Thanks, so to summarize.

## On Master:
- scalars and lists are treated as column slices
- tuples (e.g. output of IndexSlice) are passed to .loc

## This PR:
- scalars and lists are treated as
  - column slices with `axis=0`
  - index slices with `axis=1`
- tuples (e.g. output of IndexSlice) are passed to .loc  (unchanged)

Anyone else have input here? I was thinking in a "tidy data" mindset when I gave scalar / list slices a special case instead of just always passing subset to `.loc`. That may have been a bad choice since these summary tables are often not tidy. Still I'm slightly -1 on this change since I don't like the slicing logic to be spread across two parameters, but willing to be convinced otherwise.

Is ambiguity really an issue? default is axis=0 and that's pretty clear in sig. from PR

![image](https://cloud.githubusercontent.com/assets/2051736/17102696/d40db338-5248-11e6-8ae6-3ac73a126ec9.png)

Right, as long as we define it to be that way there's no ambiguity. I removed that line.

Sorry to nitpick but i think the slicing logic is already spread across 2 parameters. Although perhaps this is a separate bug or i'm doing something wrong.

IMHO this behavior is more intuitive and not ambiguous but i see your concerns. If anything we probably need to improve doc to show how to access via IndexSlice

![image](https://cloud.githubusercontent.com/assets/2051736/17103990/f2730002-524e-11e6-91ba-cd2a04186b46.png)

ok with a setup like this (number slightly switched)

```
import pandas as pd
df = pd.DataFrame(index = ['x', 'y', 'z'])
df['a'] = [1,2,3]
df['b'] = [6,5,4]
df['c'] = [7,8,9]
```

![image](https://cloud.githubusercontent.com/assets/953992/17213811/02dfd6c0-54a4-11e6-9572-3fa207482623.png)

The function is working correctly, but the API is too reminiscent of slicing and thus is ambiguous

```
def background_gradient(self, cmap='PuBu', low=0, high=0, axis=0,
                            subset=None):
        """
        Color the background in a gradient according to
        the data in each column (optionally row).
        Requires matplotlib.

        .. versionadded:: 0.17.1

        Parameters
        ----------
        cmap: str or colormap
            matplotlib colormap
        low, high: float
            compress the range by these values.
        axis: int or str
            1 or 'columns' for colunwise, 0 or 'index' for rowwise
        subset: IndexSlice
            a valid slice for ``data`` to limit the style application to
```

If `axis` instead becomes `direction=left|top` (e.g. `left` means `left-to-right` (and `right` -> `right-to-left`), and `top` -> `top-to-bottom`)

then its clear that `subset` controls slicing, and the `direction` controls gradient direction.

@TomAugspurger thoughts?

@perryvais pls rebase

@TomAugspurger comments?
closing as stale, but @TomAugspurger if you want to re-open / fixup. pls do so.