Pandas: groupby.aggでのdictの再ラベル付けの非推奨は多くの問題をもたらします

@zertrin ：これをまとめてくれてありがとう。 これについては、＃15931で多くの議論があったことがわかりました。 これを完全に読むことができなかったので、現時点ではコメントできません。 それでも、pingを実行させてください。

@jreback @jorisvandenbossche @TomAugspurger @ chris-b1

この例では、現在のagg実装での名前変更が非常に不格好で、壊れていることに同意します。 ネストされたdictはやや複雑ですが、あなたが行ったようにそれらを書くと、何が起こっているのかが非常に明確になります。

namesパラメータがagg追加され、集約列を新しい名前にマッピングする辞書が必要になる可能性があると思います。 別のパラメーターdrop_indexをブール値として追加して、上位のインデックスレベルを維持するかどうかを決定することもできます。

したがって、構文は次のようになります。

agg_dict = {'energy': ['sum',
                       lambda x: np.percentile(x, 98), # lambda
                       lambda x: np.percentile(x, 17), # lambda
                      ],
            'distance': ['sum',
                         'mean',
                         smrb.mad, # original function
                         mad_c1,   # partial function wrapping the original function
                        ]
           }

name_dict = {'energy':['energy_sum', 'energy_p98', 'energy_p17'],
             'distance':['distance_sum', 'distance_mean', 'distance_mad', 'distance_mad_c1']}


mydf.groupby('cat').agg(agg_dict, names=name_dict, drop_index=True)

または、まったく新しいメソッドagg_assignを作成することもできます。これは、 DataFrame.assignと同様に機能します。

mydf.groupby('cat').agg_assign(energy_sum=lambda x: x.energy.sum(),
                               energy_p98=lambda x: np.percentile(x.energy, 98),
                               energy_p17=lambda x: np.percentile(x.energy, 17),
                               distance_sum=lambda x: x.distance.sum(),
                               distance_mean=lambda x: x.distance.mean(),
                               distance_mad=lambda x: smrb.mad(x.distance),
                               distance_mad_c1=lambda x: mad_c1(x.distance))

私は実際、このオプションの方がはるかに好きです。

その価値については、機能を減価償却しないことにも強く賛成です。

私にとっての大きな理由は、Pythonの関数の名前空間（特定の実装に関係するもの）と列名のデータ（実装について確実に知らないはずのもの）を混合することについて、非常に奇妙なことがあるということです。 '<lambda>'という名前の列（場合によっては複数の列）が表示されているという事実は、私に深刻な認知的不協和を引き起こします。

不要な（そして公開された）列名が持ち越されるこの中間ステップがあるため、名前変更のアプローチはすごいです。 さらに、実装に依存する可能性があるため、確実に体系的に名前を変更することは困難です。

それを除けば、ネストされたdict機能は確かに複雑ですが、実行されているのは複雑な操作です。

TL; DR減価償却しないでください。 :)

私の貢献は2つのことによって動機付けられています。

1. 私はパンダの肥大化したAPIを減らす動機を認識しており、同意します。 「肥大化した」API要素を減らすという認識された動機に関して私が誤った方向に進んだとしても、PandasのAPIを合理化できると私は考えています。
2. みんなの欲求を満たすためにAPIを提供するよりも、良いレシピを持った良い料理本を持っている方が良いと思います。 ネストされた辞書を介した名前変更が、既存の気まぐれを満足させるものであると主張しているわけでは

また、PandasシリーズとDataFrameオブジェクトには、パイプライン化を容易にするためのpipeメソッドがあります。 このドキュメントセグメントでは、サブクラス化の代わりにメソッドのプロキシにpipeを使用できることが説明されています。 同じ精神で、新しいGroupBy.pipeを使用して同様の役割を実行し、groupbyオブジェクトのプロキシメソッドを構築できるようにすることができます。

@zertrinの例を使用します

import numpy as np
import statsmodels.robust as smrb
from functools import partial

# The DataFrame offered up above
mydf = pd.DataFrame(
    {
        'cat': ['A', 'A', 'A', 'B', 'B', 'C'],
        'energy': [1.8, 1.95, 2.04, 1.25, 1.6, 1.01],
        'distance': [1.2, 1.5, 1.74, 0.82, 1.01, 0.6]
    },
    index=range(6)
)

# Identical dictionary passed to `agg`
funcs = {
    'energy': {
        'total_energy': 'sum',
        'energy_p98': lambda x: np.percentile(x, 98),  # lambda
        'energy_p17': lambda x: np.percentile(x, 17),  # lambda
    },
    'distance': {
        'total_distance': 'sum',
        'average_distance': 'mean',
        'distance_mad': smrb.mad,   # original function
        'distance_mad_c1': mad_c1,  # partial function wrapping the original function
    },
}

# Write a proxy method to be passed to `pipe`
def agg_assign(gb, fdict):
    data = {
        (cl, nm): gb[cl].agg(fn)
        for cl, d in fdict.items()
        for nm, fn in d.items()
    }
    return pd.DataFrame(data)

# All the API we need already exists with `pipe`
mydf.groupby('cat').pipe(agg_assign, fdict=funcs)

その結果

            distance                                                 energy                        
    average_distance distance_mad distance_mad_c1 total_distance energy_p17 energy_p98 total_energy
cat                                                                                                
A              1.480     0.355825           0.240           4.44     1.8510     2.0364         5.79
B              0.915     0.140847           0.095           1.83     1.3095     1.5930         2.85
C              0.600     0.000000           0.000           0.60     1.0100     1.0100         1.01

pipeメソッドを使用すると、多くの場合、新しいAPIを追加する必要がなくなります。 また、これから説明している非推奨の機能を置き換える手段も提供します。 したがって、私は非推奨を進めたいと思います。

私はtdpetrouのアイデアが本当に好きです-使用する： names=name_dict 。

これはみんなを幸せにすることができます。 これにより、必要に応じて列の名前を簡単に変更

実際には、私の最初の投稿で述べたように、これでは、集計操作が定義されている場所を結果の列の名前から切り離すという問題は解決されず、両方が「同期」されていることを確認するための追加の作業が必要になります。

それが悪い解決策だとは言いませんが（結局のところ、他の問題を解決します）、dictのdictアプローチほど簡単で明確ではありません。 つまり、書き込み時には、リストの両方のdictを同期させる必要があり、ソースを読み取るとき、リーダーは、リストの2番目のdictの名前を、リストの最初のdictの集約定義と一致させるように努力する必要があります。 いずれの場合も、これは2倍の労力です。

ネストされたdictはやや複雑ですが、あなたが行ったようにそれらを書くと、何が起こっているのかが非常に明確になります。

なぜ誰もがdictのdictが複雑だと言っているように見えるのか私はまだ理解していません。 私にとって、それはそれを行う最も明確な方法です。

とはいえ、パンダチームが満足できる唯一の解決策がnamesキーワードである場合でも、それでも現在の状況を改善することができます。

@pirsquared現在のAPIを使用した興味深いソリューション。 私の意見では理解するのは簡単ではありませんが（私はそれがどのように機能するのか本当に理解していません：confused :)

私はデータサイエンスのサブレディットに関するスレッドを開始しました-パンダについて何が嫌いですか？ 。 誰かがgroupby後に返されたMultiIndexに対する軽蔑を持ち出し、plydataに実装されているdplyr do動詞を指さしました。 たまたまagg_assignまったく同じように機能するので、非常に興味深いものでした。

@zertrin agg_assignは、dict of dictアプローチよりも優れており、SQL集計と同じであるだけでなく、集計内で複数の列が相互に対話できるようにします。 また、 DataFrame.assignと同じように機能します。

@jreback @TomAugspurgerについて何か考えはありますか？

..。
mydf.groupby（ 'cat'）。agg（agg_dict、names = name_dict、drop_index = True）

これで問題は解決しますが、キーと値を2か所に揃える必要があります。 このような簿記コードを必要としないAPI（ .agg_assign提案されている）は、エラーが発生しにくいと思います。

APIを使用した後のクリーンアップコードの問題もあります。 groupby操作がMultiIndexデータフレームを返す場合、ほとんどの場合、ユーザーはMultiIndex元に戻します。 .agg_assignを使用する簡単な宣言型の方法は、階層、 MultiIndex出力、後のクリーンアップがないことを示しています。

使用パターンに基づいて、マルチインデックス出力は厳密にオプトインであり、オプトアウトではないと思います。

私は当初、 agg_assign提案に懐疑的

特に、 agg_assign(**relabeling_dict)の形式で使用して、 relabeling_dictように定義できる可能性について考えてみましょう。

relabeling_dict = {
    'energy_sum': lambda x: x.energy.sum(),
    'energy_p98': lambda x: np.percentile(x.energy, 98),
    'energy_p17': lambda x: np.percentile(x.energy, 17),
    'distance_sum': lambda x: x.distance.sum(),
    'distance_mean': lambda x: x.distance.mean(),
    'distance_mad': lambda x: smrb.mad(x.distance),
    'distance_mad_c1': lambda x: mad_c1(x.distance)
}

それは非常に柔軟で、私のOPで言及されているすべての問題を解決します。

@zertrin @ has2k1

私はこれについてもう少し考えていました、そしてこの機能はすでにapplyます。 新しい列名としてインデックスを持ち、集計として値を持つシリーズを返すだけです。 これにより、名前にスペースを含めることができ、列を希望どおりに並べ替えることができます。

def my_agg(x):
    data = {'energy_sum': x.energy.sum(),
            'energy_p98': np.percentile(x.energy, 98),
            'energy_p17': np.percentile(x.energy, 17),
            'distance sum' : x.distance.sum(),
            'distance mean': x.distance.mean(),
            'distance MAD': smrb.mad(x.distance),
            'distance MAD C1': mad_c1(x.distance)}
    return pd.Series(data, index=list_of_column_order)

mydf.groupby('cat').apply(my_agg)

したがって、新しいメソッドは必要ないかもしれませんが、代わりにドキュメントのより良い例が必要です。

@tdpetrou 、あなたは正しいです。 高速-低速パス選択プロセスでの二重実行のため、自分のバージョンを使用しているときにapplyどのように機能するかを忘れていました。

確かに、ドキュメントを読んだだけで集計コンテキストで使用することを考えた可能性はありません...
さらに、私はまだapplyの解決策が少し複雑すぎると感じています。 agg_assignアプローチは、より単純で理解しやすいように見えました。

それについての声明は実際にはなかったので、 dict-of-dictアプローチ（現在は非推奨ですが、すでに実装されており、これらすべての問題を解決します）は本当に問題外ですか？

agg_assignアプローチを除いて、 dict-of-dict依然として最も単純なアプローチのようであり、コーディングを必要とせず、非推奨ではありません。

agg_assignアプローチの利点と欠点は、列の選択を集計メソッドにプッシュすることです。 すべての例で、 x渡されるlambdaは、 DataFrameGroupByオブジェクトであるself各グループのself.get_group(group)ようなものです。 これは、 **kwargsにある名前付けを、関数にある選択範囲からきれいに分離するので便利です。

欠点は、優れた汎用集計関数が列の選択に関係している必要があることです。 フリーランチはありません！ つまり、 lambda x: x[col].minような多くのヘルパーが必要になるということです。 また、すべてのディメンションで削減されるnp.minと、 axis=0で削減されるpd.DataFrame.minなどにも注意する必要があります。 以下のような何か理由ですagg_assignと同等ではないでしょうapply 。 applyは、特定のメソッドに対して引き続き列単位で動作します。

これらのトレードオフとdict-of-dictsメソッドについてはよくわかりませんが、他の人の考えを聞いてみたいと思います。 これはagg_assign大まかなスケッチです。これは、関数が列ではなくテーブルに渡されることを強調するために、 agg_tableと呼んでいます。

from collections import defaultdict

import pandas as pd
import numpy as np
from pandas.core.groupby import DataFrameGroupBy

mydf = pd.DataFrame(
    {
        'cat': ['A', 'A', 'A', 'B', 'B', 'C'],
        'energy': [1.8, 1.95, 2.04, 1.25, 1.6, 1.01],
        'distance': [1.2, 1.5, 1.74, 0.82, 1.01, 0.6]
    },
    index=range(6)
)


def agg_table(self, **kwargs):
    output = defaultdict(dict)
    for group in self.groups:
        for k, v in kwargs.items():
            output[k][group] = v(self.get_group(group))

    return pd.concat([pd.Series(output[k]) for k in output],
                     keys=list(output),
                     axis=1)

DataFrameGroupBy.agg_table = agg_table

使用法

>>> gr = mydf.groupby("cat")
>>> gr.agg_table(n=len,
                 foo=lambda x: x.energy.min(),
                 bar=lambda y: y.distance.min())

   n   foo   bar
A  3  1.80  1.20
B  2  1.25  0.82
C  1  1.01  0.60

これのパフォーマンスをそれほどひどくしないようにするために少しできると思いますが、 .aggはありません...

Pandas Core Teamの誰かが、 groupby.aggでdictのラベル変更を廃止する主な理由を説明していただけますか？

コードを維持するのに問題が多すぎるかどうかは簡単に理解できますが、エンドユーザーの複雑さについては、必要な回避策と比較してかなり明確なので、元に戻すことも選択します...

ありがとう！

Pandasコアチームの誰かが、groupby.aggでdictのラベル変更を廃止する主な理由を説明していただけますか？

https://github.com/pandas-dev/pandas/pull/15931/files#diff -52364fb643114f3349390ad6bcf24d8fR461を見ましたか？

主な理由は、dictキーが2つのことを行うために過負荷になっていることでした。 Series / SeriesGroupByの場合、これらは名前付け用です。 DataFrame / DataFrameGroupByの場合、列を選択するためのものです。

In [32]: mydf.aggregate({"distance": "min"})
Out[32]:
distance    0.6
dtype: float64

In [33]: mydf.aggregate({"distance": {"foo": "min"}})
/Users/taugspurger/Envs/pandas-dev/bin/ipython:1: FutureWarning: using a dict with renaming is deprecated and will be removed in a future version
  #!/Users/taugspurger/Envs/pandas-dev/bin/python3.6
Out[33]:
     distance
foo       0.6

In [34]: mydf.distance.agg({"foo": "min"})
Out[34]:
foo    0.6
Name: distance, dtype: float64

In [35]: mydf.groupby("cat").agg({"distance": {"foo": "min"}})
/Users/taugspurger/Envs/pandas-dev/lib/python3.6/site-packages/pandas/pandas/core/groupby.py:4201: FutureWarning: using a dict with renaming is deprecated and will be removed in a future version
  return super(DataFrameGroupBy, self).aggregate(arg, *args, **kwargs)
Out[35]:
    distance
         foo
cat
A       1.20
B       0.82
C       0.60

In [36]: mydf.groupby("cat").distance.agg({"foo": "min"})
/Users/taugspurger/Envs/pandas-dev/bin/ipython:1: FutureWarning: using a dict on a Series for aggregation
is deprecated and will be removed in a future version
  #!/Users/taugspurger/Envs/pandas-dev/bin/python3.6
Out[36]:
      foo
cat
A    1.20
B    0.82
C    0.60

これはおそらくパンダで最も混乱することではないので、おそらく私たちはそれを再訪することができます:)私はおそらくいくつかのエッジケースを見逃しています。 ただし、dict-of-dicts集計を削除しても、名前付けと列の選択の間に矛盾があります。

Series / SeriesGroupByの場合、辞書キーは常に出力に名前を付けるためのものです。

DataFrame / DataFrameGroupbyの場合、dictキーは常に選択用です。 dict-of-dictsを使用して列を選択すると、Series / SeriesGroupByと同様に、内部dictが出力に名前を付けるためのものになります。

これについては前に簡単に説明しましたが（非推奨に関する長い議論のどこかで）、 https ：

問題は、dictが「選択」（この関数を適用する列）と「名前変更」（この関数を適用したときに結果の列名になるはず）の両方に使用されていたことでした。 agg_assign提案で説明されているように、dict以外の代替構文は、キーワード引数である可能性があります。
それがagg自体にあるか、 agg_assignような新しい方法にあるかにかかわらず、私はまだこの可能性を探求することに賛成です。

当時私が提案したのはagg_assign似ていますが、ラムダ関数の代わりにキーワードごとにdictを使用していました。 ここの例に翻訳すると、これは次のようになります。

mydf.groupby('cat').agg(
    energy_sum={'energy': 'sum'},
    energy_p98={'energy': lambda x: np.percentile(x, 98)},
    energy_p17={'energy': lambda x: np.percentile(x, 17)},
    distance_sum={'distance': 'sum'},
    distance_mean={'distance': 'mean'},
    distance_mad={'distance': smrb.mad},
    distance_mad_c1={'distance': mad_c1})

すべてのラムダを含むバージョンとして、これが必ずしも読みやすく、書きやすいかどうかはわかりませんが、パンダは、実行する列で合計、平均などに最適化された実装を使用できるため、パフォーマンスが向上する可能性があります。ラムダ関数またはユーザー指定関数はありません。

このアプローチの大きな問題は、 df.groupby('cat').agg(foo='mean')が何を意味するのかということです。 これは、選択を行わなかったため、すべての列に「mean」を論理的に適用します（以前の{'col1' : {'foo': 'mean'}, 'col2': {'foo':'mean'}, 'col3': ...}と同様）。 ただし、これによりマルチインデックス列が作成されますが、上記の例では、MI列で終わらないようにするとよいと思います。

上記は既存のagg内で下位互換性があると思いますが、問題はこれが必要かどうかです。
また、これは次のようなseries場合にもうまく拡張できると思います。

mydf.groupby('cat').distance.agg(
    distance_sum='sum',
    distance_mean='mean',
    distance_mad=smrb.mad,
    distance_mad_c1=mad_c1)

（そして、上記を「距離」に対して1回、「エネルギー」に対して1回実行し、すべてのdict /ラムダが気に入らない場合は結果を連結することも検討できます）

@TomAugspurger agg_table単純な実装例では、グループを反復するのではなく、適用するさまざまな関数を反復し、最終的に新しい列をaxis = 1で連結する方がよいでしょう。新しく形成された行をaxis = 0で連結する代わりに？

ところで、 @ zertrin @tdpetrou @smcateer @pirsquaredなど、この問題を提起し、そのような詳細なフィードバックを提供してくれてありがとう。 このようなフィードバックとコミュニティの関与は非常に重要です。

私は実際に@tdpetrouによって提案されたパターンが本当に好き

関数がpd.Series(data, index=data.keys())返す場合、正しい順序でインデックスを取得することが保証されていますか？ （私のコードにパターンを実装するための最良の方法を考えているだけです-トピックから外れるリスクがあります）。

編集：申し訳ありませんが、インデックス引数のポイントを誤解しました（ここではオプションであり、列の順序を指定する場合にのみ必要です。 pd.Series(data)返すとうまくいきます）。

@tdpetrouの例は、 firstとlast集計で機能しますか？

私はこのように頭/尾に頼らなければなりませんでした

def agg_funcs(x):
    data = {'start':x['DATE_TIME'].head(1).values[0],
           'finish':x['DATE_TIME'].tail(1).values[0],
           'events':len(x['DATE_TIME'])}
    return pd.Series(data, index = list(data.keys()))

results = df.groupby('col').apply(agg_funcs)

私はまだこれに対処したいと思いますが、0.23で行われるとは思いません。

@tdpetrouのアプローチは、コードで二度と使用しない関数を定義しなくても機能しますか？ Q / Kdb +の世界（SQLと同様）から来ているので、単純なselectステートメントの時間変数/関数を作成する必要がある理由がわかりません。

ここでOP。

正直なところ、これまでのすべての時間と＃15931とここでの多くの議論の後、私はこれが再ラベル付けの口述を非推奨にする良い考えであるとまだ確信していません。

結局、ここで提案された代替案はどれも、現在の再ラベル付けdictアプローチIMHOよりもユーザーにとって直感的ではありません。 それがドキュメントにあったとき、ほんの一例で、これがどのように機能するかが明確であり、非常に柔軟性があります。

もちろん、パンダの開発者はまだ別のことを考えているかもしれません。ユーザーの視点にとらわれているだけです。

dictの再ラベル付けアプローチでさえ、あまり直感的ではありません。 私の意見では、構文はSQL- func(column_name) as new_column_name似ているはずです。 Pythonでは、3項目のタプルを使用してこれを行うことができます。 (func, column_name, new_column_name) 。 これは、dexploがgroupby集計を行う方法です。

@zertrin上記の私の提案についてフィードバックがありますか： https ：
結局、それはdictの順序を逆にします。「{col：{name：func}}」の代わりに、「** {name：{col：func}}」のようなものになります。

@jorisvandenbossche私はあなたのアプローチを検討しました。 問題は、それが現在のアプローチにどのような追加の利点をもたらすのか、私にはよくわかりません。

もっと率直に言うと、次の選択肢があります。

1. 正常に機能する現在の動作の非推奨を解除します（数行の非推奨コードを削除し、削除されたドキュメントを再度追加します）
2. 提案を実装します（コードに大幅な変更を加え、現在のアプローチを廃止して追求し、すべてのユーザーがコードを適応させる必要があります）

開発者とユーザーの観点から意味のある具体的な利点がもたらされない限り、なぜ2を選択する必要があるのか​​わかりません。

上記の提案のいくつかのポイントに対処するには：

問題は、dictが「選択」（この関数を適用する列）と「名前変更」（この関数を適用したときに結果の列名になるはず）の両方に使用されていたことでした。

以前はうまく文書化されていたので、ユーザーにとっては問題ではなかったと思い

dicts以外の代替構文は、キーワード引数である可能性があります

dict-of-dictアプローチを使用する魅力的な点の1つは、ユーザーが他のコードを使用して動的に簡単に生成できることです。 このコメントのすぐ上のコメントで指摘したように、命題のようにキーワード引数に移動しても、 **{name: {col: func}}構造を介してこれを行うことができます。 だから私はあなたの提案に反対していません。 現在実装されているシステムと同じレベルの機能をすでに実現しているのに、付加価値やそのような変更の必要性がわかりません。

結局、パンダのコア開発者が現在のアプローチに対して強い感情を持っている場合、あなたの提案は_大丈夫_になります。 _user_としてのメリットは見当たりません。 （実際、既存のすべてのユーザーコードを変更して、新しい提案で再び機能させることには欠点があります）。

@zertrin昨日、いくつかのコアに答える

したがって、最初に述べると、SQL "SELECT avg（col2）as col2_avg"のような基本的な機能は機能し、簡単である必要があるという概念は、私たちが完全に同意するものであり、これに対する解決策が本当に必要です。

これはあなたが実際たくないというマルチインデックスを作成するとは別に、オリジナルの理由から、私たちは、dictsの現在の（非推奨）dictsもないことが理想的である、（またはその強いであってもなくてもよい）、これを廃止することを決めました。

In [1]: df = pd.DataFrame({'A': ['a', 'b', 'a'], 'B': range(3), 'C': [.1, .2, .3]})

In [3]: gr = df.groupby('A')

In [4]: gr.agg({'B': {'b_sum': 'sum'}, 'C': {'c_mean': 'mean', 'c_count': 'count'}})
Out[4]: 
        C            B
  c_count c_mean b_sum
A                     
a       2    0.2     2
b       1    0.2     1

上記では、列の名前を具体的に変更しているため、MultiIndexの最初のレベルは不要です（OPの例では、この直後に列の最初のレベルを削除します）。
ただし、MultiIndexが必要であり、理にかなっている場合は、 gr.agg(['sum', 'mean'])や（混合） gr.agg({'B': ['sum', 'mean'], 'C': {'c_mean': 'mean', 'c_count': 'count'}})なども実行できるため、これを変更するのは困難です。

したがって、上記の説明で言及された提案の1つは、最終的な列名を個別に指定する方法を用意することでした（たとえば、https：//github.com/pandas-dev/pandas/issues/18366#issuecomment-346683449）。
たとえば、 aggregateに追加のキーワードを追加して、次のように列名を指定します。

gr.agg({'B': 'sum', 'C': ['mean', 'count']}, columns=['b_sum', 'c_mean', 'c_count'])

可能だろう。
ただし、列/関数の仕様と新しい列名を分割すると、これを新しいキーワードよりも一般的にして、次のようにすることもできます。

gr.agg({'B': 'sum', 'C': ['mean', 'count']}).rename(columns=['b_sum', 'c_mean', 'c_count'])

これを解決するには、 https：//github.com/pandas-dev/pandas/issues/14829が必要です（0.24.0で実行したいこと）。
（重要な注意：このためには、ラムダ関数の名前の重複の問題を修正する必要があるため、このソリューションをサポートする場合は、名前のある種の自動重複排除を実行する必要があります。）

それでも、名前を変更するためのキーワード引数の方法は気に入っています。 この理由は次のとおりです。

• これは、パンダでのassign動作に似ており、イビスでのgroupby().aggregate()動作にも似ています（たとえば、Rのdplyrでの動作にも似ています）。
• 必要な非階層列名を直接提供します（MultiIndexなし）
• 単純な場合（たとえば、シリーズの場合）、dictのdictとしてより単純だと思います

それがどのように見えるかについては、まだ少し議論がありました。 上で提案したのは（最初の例と同等の列/関数の選択を使用するため）：

gr.agg(b_sum={'B': 'sum'}, c_mean={'C': 'mean'}, c_count={'C': 'count'})

dictのdictとしてこの仕様を構築することはできますが、現在の（非推奨の）バージョンと比較して内部レベルと外部レベルを入れ替えています。

gr.agg(**{'b_sum': {'B': 'sum'}, 'c_mean': {'C': 'mean'}, 'c_count': {'C': 'count'})

（dictの既存のdictをこのバージョンに変換するヘルパー関数の例があります）

ただし、dictは常に単一の{col: func}であり、これらの複数の単一要素のdictは少し奇妙に見えます。 したがって、私たちが考えた代替案は、タプルを使用することです。

gr.agg(b_sum=('B', 'sum'), c_mean=('C', 'mean'), c_count=('C', 'count'))

これは少し良く{'B': 'sum'} dictは、関数を適用する列を指定するための他のAPIと一致しています。

上記の両方の提案（後で名前を変更するのが簡単で、キーワードベースの名前付け）は原則として直交していますが、両方（またはさらなる議論に基づいてさらに何か）があると便利です。

ここに開発者からの現在の考えを転送していただきありがとうございます😃

私の意見では、非推奨のdict-of-dictアプローチと結果として得られるMultiIndexの欠点を認めます。 ユーザーが追加のオプションを渡すと、フラット化される可能性があります（ええYAO：-/）。

前述のように、次のことが可能な限り、私は2番目のバージョンに反対していません。

• なんとかして動的に物事を生成し、それを解凍します（ **{}コンストラクトのおかげで、Pythonです！）
• 名前の変更と集計の仕様を近づけてください（順序が同じになるように2つのリストを追跡する必要があるのは、ユーザーの私見としては明らかに面倒です）
• 関数名が（潜在的に欠如しているか、競合している）ため、回避策を必要とせずにラムダ関数または部分関数を使用します。

そのため、最後の提案（col> funcマッピングのdictまたはタプルを使用）は大丈夫だと思います。

前のコメントの最初の提案は、本当に必要な場合に実装できますが、これに関する私のフィードバックは、ユーザーとして、物事の同期を維持するのが面倒なため、2番目の選択肢よりも使用することを選択しないということです。 2つのリスト。

今日の開発者会議で議論されました。

簡単な要約

1. @jorisvandenbosscheはgr.agg(b_sum=("B", "sum), ...)を実装しようとします。つまり、 argが*GroupBy.aggに渡されない場合、kwargsを<output_name>=(<selection>, <aggfunc>)として解釈します。
2. この問題に直交して、 MutliIndex.flattenを実装し、 flatten=Trueキーワードを.agg提供したいと思います。

たぶんこれは役に立ちます：非推奨の私の回避策は、alias-> aggrマップを正しく名前が付けられた関数のリストに置き換えるこれらのヘルパー関数です：

def aliased_aggr(aggr, name):
    if isinstance(aggr,str):
        def f(data):
            return data.agg(aggr)
    else:
        def f(data):
            return aggr(data)
    f.__name__ = name
    return f

def convert_aggr_spec(aggr_spec):
    return {
        col : [ 
            aliased_aggr(aggr,alias) for alias, aggr in aggr_map.items() 
        ]  
        for col, aggr_map in aggr_spec.items() 
    }

これにより、古い動作が次のようになります。

mydf_agg = mydf.groupby('cat').agg(convert_aggr_spec{
    'energy': {
        'total_energy': 'sum',
        'energy_p98': lambda x: np.percentile(x, 98),  # lambda
        'energy_p17': lambda x: np.percentile(x, 17),  # lambda
    },
    'distance': {
        'total_distance': 'sum',
        'average_distance': 'mean',
        'distance_mad': smrb.mad,   # original function
        'distance_mad_c1': mad_c1,  # partial function wrapping the original function
    },
}))

これはと同じです

mydf_agg = mydf.groupby('cat').agg({
    'energy': [ 
        aliased_aggr('sum', 'total_energy'),
        aliased_aggr(lambda x: np.percentile(x, 98), 'energy_p98'),
        aliased_aggr(lambda x: np.percentile(x, 17), 'energy_p17')
    ],
    'distance': [
         aliased_aggr('sum', 'total_distance'),
         aliased_aggr('mean', 'average_distance'),
         aliased_aggr(smrb.mad, 'distance_mad'),
         aliased_aggr(mad_c1, 'distance_mad_c1'),
    ]
})

これは私にとってはうまくいきますが、いくつかのコーナーケースではおそらくうまくいかないでしょう...

更新：集計仕様のタプルは（エイリアス、aggr）として解釈されるため、名前の変更は不要であることがわかりました。 したがって、alias_aggr関数は不要であり、変換は次のようになります。

def convert_aggr_spec(aggr_spec):
    return {
        col : [ 
           (alias,aggr) for alias, aggr in aggr_map.items() 
        ]  
        for col, aggr_map in aggr_spec.items() 
    }

関数の列を集約してすぐに同じ行の名前を変更する機能が本当に不足している別のユーザーとして、ここでチャイムを鳴らしたいと思います。 パンダから返されたMultiIndexを使用していることに気付いたことがありません。すぐにフラット化するか、実際には特定の意味を持つ列名を手動で指定したいと思います。

ここで提案されているアプローチのいずれかに満足します。SQLのような構文（実際にはすでにパンダで.query()を頻繁に使用しています）、減価償却された動作に戻る、その他の提案。 現在のアプローチでは、Rを使用している同僚からすでに嘲笑されています。

私は最近、構文が非常に好きであるという理由だけで、パンダの代わりにPySparkを使用していることに気付きましたが、それは必要ではありませんでした。

df.groupby("whatever").agg(
    F.max("col1").alias("my_max_col"),
    F.avg("age_col").alias("average_age"),
    F.sum("col2").alias("total_yearly_payments")
)

また、PySparkは、ほとんどの場合、パンダよりも書くのがはるかに複雑です。これは非常にきれいに見えます。 だから私は間違いなくこれに関する作業がまだ行われていることを感謝しています:-)

この機能については、合意された構文があると思います。 誰かが必要です
それを実装します。

9:01トーマスKastlの水、2019年3月27日には[email protected]
書きました：

本当に本当に本当に別のユーザーとしてここでチャイムを鳴らしたいだけです
関数の列を集約する機能がなく、
すぐに同じ行の名前を変更します。 私は自分自身を見つけたことがありません
パンダから返されたMultiIndexを使用する-私はすぐにそれを平坦化するか、
または、列名を手動で指定したいのは、
実際には特定の何かを意味します。

ここで提案されているアプローチのいずれかに満足します：SQLのような構文
（私は実際にパンダで.query（）を頻繁に使用していることに気づきました）、
減価償却された動作に戻る、他の提案のいずれか。 The
現在のアプローチでは、Rを使用している同僚からすでに嘲笑されています。

私は最近、パンダの代わりにPySparkを使用していることに気づきました。
構文がとても好きだからという理由だけで、それは必要ではありませんでした。

df.groupby（ "whatever"）。agg（F.max（ "col1"）。alias（ "my_max_col"）、
F.avg（ "age_col"）。alias（ "average_age"）、
F.sum（ "col2"）。alias（ "total_yearly_payments"））

また、PySparkは、ほとんどの場合、パンダよりも書くのがはるかに複雑です。
これはとてもきれいに見えます！ だから私は間違いなくその作業に感謝します
これはまだ行われています:-)

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/pandas-dev/pandas/issues/18366#issuecomment-477168767 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ABQHIkCYYsah5siYA4_z0oop_ufIB3h8ks5va3nJgaJpZM4QjSLL
。

0.25.0でこれに到達しようとしています

https://github.com/pandas-dev/pandas/pull/26399にPRを(selection, aggfunc)タプルである必要があることを理解した上で、 **kwargsを使用して、名前変更と列固有の集計をこのように組み合わせることを許可することです。

In [2]: df = pd.DataFrame({'kind': ['cat', 'dog', 'cat', 'dog'],
   ...:                    'height': [9.1, 6.0, 9.5, 34.0],
   ...:                    'weight': [7.9, 7.5, 9.9, 198.0]})

In [3]: df
Out[3]:
  kind  height  weight
0  cat     9.1     7.9
1  dog     6.0     7.5
2  cat     9.5     9.9
3  dog    34.0   198.0

In [4]: df.groupby('kind').agg(min_height=('height', 'min'), max_weight=('weight', 'max'))
Out[4]:
      min_height  max_weight
kind
cat          9.1         9.9
dog          6.0       198.0

これにはいくつかの制限があります

• それは他のパンダにいくらか独特です。 sytanx (output_name=(selection, aggfunc))は、実際には他の場所には表示されません（ただし、 .assignはoutput_name=...パターンを使用します）
• Python識別子ではない出力名のスペルは醜いです： .agg(**{'output name': (col, func)})
• Python 3.6以降のみです。または、 **kwargsの順序が以前は保持されていなかったため、3.5以前では醜いハックが必要です。
• aggfuncは単項関数である必要があります。 カスタムaggfuncに追加の引数が必要な場合は、最初に部分的に適用する必要があります

また、実装の詳細があります。同じ列に対する複数のlambda aggfuncsはまだサポートされていませんが、後で修正できます。

ここでサブスクライブしているほとんどの人は、非推奨の動作に代わるいくつかの方法を支持していると思います。 人々はこれを具体的にどう思いますか？

私があなたの懸念のいずれかを逃した場合はcc @ WillAyd 。

こんにちは@TomAugspurger 、

これを前進させてくれてありがとう。

これにはいくつかの制限があります

• それは他のパンダにいくらか独特です。 sytanx (output_name=(selection, aggfunc))は、実際には他の場所には表示されません（ただし、 .assignはoutput_name=...パターンを使用します）

この種の議論は、そもそも既存の実装を廃止する動機となったものと非常に似ているように思わざるを得ません。

_その特定の議論に関して_、なぜ私たちが古い方法よりもこの新しい方法からより多くの利益を得るのかを共有できますか？

私がすでに考えている利点の1つは、（py3.6 +の場合）列の出力順序を個別に選択できることです。

• Python識別子ではない出力名のスペルは醜いです： .agg(**{'output name': (col, func)})

どういうわけか、その点では古い方法の方が優れていました。 しかし、前に述べたように、 **{...}構造を使用して動的に集計を構築できる限り、私は十分に満足しています。

• Python 3.6以降のみです。または、 **kwargsの順序が以前は保持されていなかったため、3.5以前では醜いハックが必要です。

以前はどのように機能していましたか（既存のdict-of-dict機能）？ 注文は何らかの方法で保証されましたか？

• aggfuncは単項関数である必要があります。 カスタムaggfuncに追加の引数が必要な場合は、最初に部分的に適用する必要があります

私の理解を確認するために：aggfuncは、有効な値を返す任意の呼び出し可能である可能性がありますか？ （ 'min' 、 'max'などの「よく使用される」文字列aggfungsに加えて）。 以前との違いはありますか？ （つまり、単項制限はすでに存在していませんでしたか？）

また、実装の詳細があります。同じ列に対する複数のlambda aggfuncsはまだサポートされていませんが、後で修正できます。

ええ、それはちょっと面倒ですが、それが一時的な制限であり、これを修正することができる限り、それはうまくいく可能性があります。

ここでサブスクライブしているほとんどの人は、非推奨の動作に代わるいくつかの方法を支持していると思います。 人々はこれを具体的にどう思いますか？

とにかく、1つのステップで集約して名前を変更することは、維持することが非常に重要だと思います。 古い動作が実際にはオプションではない場合は、この代替手段で実行できます。

その特定の議論に関して、なぜ私たちが古い方法よりもこの新しい方法からより多くの利益を得るのかを共有できますか？

覚えていないかもしれませんが、SeriesGroupby.aggとDataFrameGroupby.aggは、辞書の外部キー間で異なる意味を持っていると思います（列の選択ですか、それとも出力の名前ですか？）。 この構文を使用すると、キーワードに出力名を一貫して意味させることができます。

どういうわけか、その点では古い方法の方が優れていました。

違いは**ですか？ そうでなければ、同じ制限が共有されていると思います。

以前はどのように機能していましたか（既存のdict-of-dict機能）？ 注文は何らかの方法で保証されましたか？

キーの並べ替え。これは、現在PRで行っていることです。

私の理解を確認するために：aggfuncは、有効な値を返す任意の呼び出し可能である可能性がありますか？

これが違いです

In [21]: df = pd.DataFrame({"A": ['a', 'a'], 'B': [1, 2], 'C': [3, 4]})

In [22]: def aggfunc(x, myarg=None):
    ...:     print(myarg)
    ...:     return sum(x)
    ...:

In [23]: df.groupby("A").agg({'B': {'foo': aggfunc}}, myarg='bar')
/Users/taugspurger/sandbox/pandas/pandas/core/groupby/generic.py:1308: FutureWarning: using a dict with renaming is deprecated and will be removed in a future version
  return super().aggregate(arg, *args, **kwargs)
None
Out[23]:
    B
  foo
A
a   3

別の提案では、出力列名用に**kwargsを予約しています。 したがって、 functools.partitial(aggfunc, myarg='bar')する必要があります。

おかげで、提案されたアプローチは最初の反復では👍だと思います（そして、複数のラムダ実装の制限が取り除かれるとすぐに、置き換えとして本当に大丈夫です）