Python 内包表記の限界: 複雑な処理と実行速度の関係 - Qiita

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

[JULY]

内包表記をパフォマンス目的で書くことは無いなぁ。基本、「ロジックとして重要ではないデータ抽出、変換処理」が行数とインデントを使い、本来のロジックの可読性の邪魔となるのを避けるために使う。

[hylom]

リスト内包が速いのはメモリ操作の関係上入力と出力の要素数が同じ場合のみだと認識している。要素の抜き出しをするならおとなしくfilter()使う方が良いのでは

[sisya]

内包表記で複雑なことをするときはもう割り切って多めのコメント文をつけるようにしている。極端な話、内包表記を使わないコードをコメントブロックで上に置いておくくらいでもいいのでは。(修正コストは上がる)

[yojik]

明らかに内包表記の方が読みやすい。集計してdictにまとめ直すとか、 for文の方が読みやすくなる例はもっとありそうだけど。。 / あとpersonの複数形が気になる。。(古語とかにはあるらしいけど...)

[naka-06_18]

filter って文字数多いよね

[perl-o-pal]

んー、内包表記の方が可読性よくない？//というか、素直にfilterとか使いたいけど、いちいちlambdaってかくのが面倒なんだよなあ。haskellの\くらい簡略ならいいのに。

[Ho-oTo]

内包表記の良いところ、Pythonのアレなスコープ仕様を迂回できる点もデカい気がする

[amd64x64]

loop内でappendせず外でresult=[None]*ELEMENTしてからresult[i]=iしたほうがいいよ。reserve大事。

[rryu]

リストへの追加をバイトコードLIST_APPENDでやるかメソッド呼び出しでやるかの差しか無いと。

[zgmf-x20a]

お疲れ様でした。

[UhoNiceGuy]

リストの内包表記って、map、filterをわかりやすく表記するものでしょ。for loopと比べて一目瞭然。for loopはなんでも出来すぎるんだよ

[tettekete37564]

へーバイトコード確認とか出来るんだ。

[yarumato]

“速度のために内包表記を使うことが合理的かどうか検証。簡単な処理なら速度上がることもある。複雑な処理なら速度変わらないので、わざわざ「可読性の悪い」内包表記で行う意味はほぼ無い”

[aya_momo]

Pythonの内包表記で複雑なことはしないよ。他でもそう。

[mattn]

おもしろい。

[asiamoth]

だいたい実感と合った結論。forループ抜けたら不要なtmp変数が散見する場合くらいで良いよね、内容記法。が、ちゃんとコードがあってベンチマークを計ってあると安心する。