API change in groupby head and tail

[hayd]

BUG/API groupby head and tail act like filter, since they dont aggregage fixes column selection

Breaking API change to groupby head and tail, these were never aggregated output, so should not have the group labels as the index, it should always filter. (It was a legacy from when this was g.apply(lambda x: x.head(n)).)

        as_index : boolean, default True
            For aggregated output, return object with group labels as the
            index. Only relevant for DataFrame input. as_index=False is
            effectively "SQL-style" grouped output

Also fixes the column selection for head and tail

part of #5755
related #6524
part of #5264.

cc @jreback @TomAugspurger

[hayd]

Note: definitely need to change some documentation here if we were to do this, but thought should put change out there. / discuss

[jreback]

@hayd this is good

why don't you add doc change in v0.14.0 (and in groupby.rst) for this change,

then in #5264 can expand that?

I edited the top to show this closes #5755 (only), others are related, right?

@TomAugspurger

[hayd]

@jreback is a partial close 5755 (I'll make a checklist on that, some of it's also up for discussion, should clean it up in one-hit IMO - this coming release). Ok, cool, will trawl through the docs to see what needs changing and add twice in release.

[TomAugspurger]

Yeah this looks good. I'm looking forward to more consistency in groupby :)

[hayd]

Updated... Something has broken the build (first commit passed travis and second only changes docs)!

[jreback]

hmm..travis seems flaky right now....wait before merging this...let's see if can fix travis

[jreback]

looks like whl are not being transported properly....(though I just accessed the server ok)....maybe a network issue from travis?

[jreback]

@hayd

shouldn't this level be named? (e.g. its the original index of the frame)

http://stackoverflow.com/questions/22210865/python-assign-values-to-first-observation-of-each-group-in-dataframe/22210998#22210998

maybe make a first_index() function?

[jreback]

@hayd I realize that this is a case where as_index=False actually is useful!

[hayd]

@jreback haha, but you won't need to with this PR :) Ah, the unnamed level is from the original index (which had no name), no?

Is pretty easy to write with cumcount:

g.first_index == df[g.cumcount() == 0] ?

(s390x ?!!)

[jreback]

I thought he said mainframe. that's something the sparc guys can't even get numpy to run on, yet they want pandas to run ...meh

[hayd]

@jreback you want me to rebase/amending? I want to do the nth stuff on top of this so would be good to merge. (I tried amending before but it failed)

[jreback]

go ahead.....you can prob just merge this... (not sure why travis is acting up stilll)

[hayd]

we'll see...

[hayd]

yeah, build still failing.