ENH: Have pivot and pivot_table take similar arguments
State: closed

Right now, there is 

```
df.pivot(index=foo, columns=bar, values=baz)
```

and

```
df.pivot_table(rows=foo, cols=bar, values=baz)
```

Because of dirtyness in my data I occasionally have to go back and forth between the two forms (and use `df.pivot_table(..., aggfunc='count')` to see who had the bad data).  It would be nice if I didn't have to change the keyword arguments each time and one had an alias of the other.  It would also be easier to remember, especially in the trivial case of `cols` vs `columns`.  Finally, the two are related operations and having an option for consistent keyword parameters makes sense.

I could make a PR to solve this easy enough, if this is an enhancement you are interested in.  I'm not really sure what your stance is on redundant keyword arguments.


Labels:
name: Reshaping
description: Concat, Merge/Join, Stack/Unstack, Explode
name: API Design

Comments:
If you want to propose something we'd likely be open to it (depending on
how much the API is changed), but you'd also need to maintain order of
arguments. Probably easiest to just add **kwargs to it and then validate
that only cols or columns were passed and then just convert to what
function expects

I guess the problem is that the API (order of args) won't be changed, so it's not really going to ever fully fix... :(

@hayd hopefully my last commit addresses your concerns.

A remark: would it make sense to choose which of the keywords (col/columns and rows/index) is preferential and only provide those to the other function (and not have both options in both functions)?

@jsexauer does this have an issue? (aside from this PR)

Not sure what you're asking @jreback.  The included PR, which has no issues to my knowledge, fixes the issue regarding a discrepancy between the parameters for `pivot` and `pivot_table`.

am asking if their is a reference issue for this (eg a prior issue); guess not

I submitted this originally as an issue ticket but changed into a PR ticket when I coded the enhancement.

This has tripped me in the past, so I think I'm +1 on this.

I've implemented @hayd 's suggestions.

(waiting til after 0.13 is final, but then it would need something in release notes and some tests, sorry I hadn't realised there were no tests  'til just now!)

I want to repeat my remark (as there was not really a response). Isn't it possible to really make it more consistent instead of just providing both options to both functions as additional keyword arguments?
- for `cols/columns` we could choose one of the two as the preferential one. E.g. choosing for `columns`, and only add it as a keyword argument to `pivot_table` (and not also add `cols` to `pivot`). 
  I think it would maybe even be possible to change `cols` to `columns` in the default function call of `pivot_table`, and provide `cols` as additional one (so both argument by order as by name still works, no backwards incompatible change, but the function call itself are also more consistent).
- for `index/rows` it is maybe less clear wich is the preferential?

+1 on joris suggestion

maybe attach a depr warning to use of cols?

columns and index would be the most consistent with the rest of pandas, though rows is ok 2 (definitely not cols though)

I think lets break `pivot_table` and just go with `pivot` args; you can for 0.14 provide a nice warning message, but I would just change the signature to using `index/columns`. This is used everywhere else; `rows/cols` not used anywhere. 

should probably deprecate old args too.

@jsexauer can you respond to @hayd comments?

Assuming this passes CI, I believe this addresses everyone's concerns.  Sorry for the delay.

ok that's fine about the deprecated args then
pls open an issue for their removal in the next version (reference this issue)
I'll mark it as a reminder

Do I have to do something to get TravisCI to run on this?  Last time, the commits just automatically got picked up, but the haven't this time time.

You have to rebase I think because it cannot be merged cleanly, and also best squash a bit the commits.

Not sure how to squash the commits, but I think I'm up to the present master branch now.  Is there anything else I need to do?  Thanks for all the help.

To rebase and squash, do:

```
git fetch upstream
git rebase --interactive upstream/master 
```

and then you can replace `pick` with `squash` for the commits you want to meld into the previous one. 

Ok good to know.  Sorry you're going to get my full commit history then.  I will do this in the future.

But you can do it now, that is no problem. 
If you just execute the lines above, you should be able to meld all the commits into one or a few. 

God I hope I did this right...

Hmm, you have one commit (the third last one) that seems a squashed one, but the original commits are not gone, so clearly something went wrong, but I don't know what.

If git rebase -i does not work, another option is to create a new branch and cherry-pick that one commit that is the good one, something like:

```
git checkout master
git rebase upstream/master
git checkout -b new_branch
git cherry-pick 1e1caf6e367d1f04cfce43cdff062e80bb99ebaf
```

and then push this branch (to a new PR)

So I deleted branch fix5505 on my local repo, and created a new version which was a squashed rebase of commit e3dad66 onto upstream/master (which is commit 0d74287).  I then tried to push this new version of branch fix5505 onto jsexauer/pandas/fix5505 but it said I had to pull down the old version first, so I made a new empty commit [2409c0e] to make it happy.  If there's a better way to do this last step, let me know, but this was the best I could figure out short of opening a new PR.  If you'd prefer I did that I will, but it seems like it would be best to keep this mess in one ticket instead of spreading the wealth :)

You have to force push at the end (as you've changed the history), you've now done it as a merge. Best advice is to create new branch off master and cherry-pick as Joris describes. then **force push**.

```
git push origin new_branch:fix5505 --force
```

Bam, looks good I think?

I'm really at a loss, as the test it fails on works for me:

```
import pandas
import numpy as np
import pandas.util.testing as tm

index = ['A', 'B']
columns = 'C'
df = pandas.DataFrame({'A': ['foo', 'foo', 'foo', 'foo',
                                     'bar', 'bar', 'bar', 'bar',
                                     'foo', 'foo', 'foo'],
                               'B': ['one', 'one', 'one', 'two',
                                     'one', 'one', 'one', 'two',
                                     'two', 'two', 'one'],
                               'C': ['dull', 'dull', 'shiny', 'dull',
                                     'dull', 'shiny', 'shiny', 'dull',
                                     'shiny', 'shiny', 'shiny'],
                               'D': np.random.randn(11),
                               'E': np.random.randn(11),
                               'F': np.random.randn(11)})

with tm.assert_produces_warning(FutureWarning):
    pandas.pivot_table(df, values='D', rows=index,
                                    cols=columns)

with tm.assert_produces_warning(False):
    pandas.pivot_table(df, values='D', index=index,
                                    columns=columns)

pandas.pivot_table(df, values='D', rows=index,
                                cols=columns)
```