Code Sample, a copy-pastable example if possible
# Your code here
import pandas as pd
from pandas import DataFrame,Series
ages = [20,22,25,27,21,23,37,31,61,45,41,32]
bins = [18,25,35,60,100]
group_names = ['Youth','YoungAdult','MiddleAged','Senior']
pd.cut(ages,bins,labels=group_names)
cuts.labels
/Users/****/anaconda/bin/ipython:1: FutureWarning: 'labels' is deprecated. Use 'codes' instead
#!/Users/****/anaconda/bin/python
Out[134]: array([3, 3, 3, 2, 3, 3, 0, 2, 1, 0, 0, 2], dtype=int8)
In [135]: cuts.codes
Out[135]: array([3, 3, 3, 2, 3, 3, 0, 2, 1, 0, 0, 2], dtype=int8)
Problem description
pd.cut() support argument labels not codes but the getter of the property support codes not labels
Expected Output
Output of pd.show_versions()
Comment From: jreback
this is as expected. pd.cut returns a categorical where the spelling for 'labels' is called categories. .labels is deprecated on a Categorical. Historically this argument has been named labels in the cut/qcut. I suppose we could accept cateogories as well (or maybe just deprecate labels, only +0 on this.
@TomAugspurger @chris-b1
Comment From: HinataHinata
I understand. but it is still a little bit werid. I think the setter and the getter is the same is better. perhaps support both 'labels' and 'cateogories' is better.
Comment From: jorisvandenbossche
I am not sure it is worth to deprecate it here.
Note that 'labels' in some sense is still correct, because you do not specify the actual categories for the input data (as this are the bins), but the 'labels' for the resulting categories .. (of course how to interprete it is a bit subjective, but for me that is another reason I don't see the need to deprecate the labels kwarg).
Comment From: TomAugspurger
Agreed w/ not deprecating.
Comment From: jreback
closing as usage question.
@HinataHinata I think this is pretty clear from the doc-string, but as always if it is not, then a PR to make it better would be great.
