Pythonのお勉強 Part75 (800ﾚｽ)
上下前次1-新
1: (ﾜｯﾁｮｲ 33d8-PysV) 04/04(金)01:47 ID:UMpXJcmx0(1/4) AAS
!extend:default:vvvvv:1000:1024
!extend:default:vvvvv:1000:1024
↑スレ立てる毎に減るので、減ってたら３つに補充すること。
※前スレ
Pythonのお勉強 Part74
2chｽﾚ:tech
VIPQ2_EXTDAT: default:vvvvv:1000:512:: EXT was configured VIPQ2_EXTDAT: default:vvvvv:1000:512:: EXT was configured
771(1): (ﾜｯﾁｮｲ 6aea-hBFX) 08/25(月)00:15 ID:FnDhpDPk0(1/3) AAS
慣れなんかな
巨大な行列が控えてる時の
そんでもなんか人間の認知と違う気がする
772(1): (ﾜｯﾁｮｲ 6a31-uCg5) 08/25(月)01:44 ID:cafSUUHh0(1) AAS
>>771
構文の話をするやつは道具の良し悪しばかりで論じて仕事はさっぱりできない人間
773: (ﾜｯﾁｮｲ adf5-3/RT) 08/25(月)03:06 ID:CxzN3iJP0(1/3) AAS
lambdaもだけど1行に複数の要素が入るととたんに可読性落ちるんで
そこは自制するのがクールという文化(Pythonic)
lambdaはdef、内包表記は複数行にするかforで書きなおす
774(1): (ﾜｯﾁｮｲ 41e8-ZAtR) 08/25(月)09:43 ID:8weJ9FR00(1/2) AAS
lambdaに文は入れられないが、文を含むような場合は名前あり関数として定義する方がわかりやすい……というのが一般論として常に正しいかは相当に疑問だけど。たとえば引数をそのままprintするようなごく単純なコードでも（lambdaにはできないので）名前あり関数にしなければいけないというのはかなりダルい。
Pytnonの文化は文化として尊重するし、実際、概ね妥当なアドバイスになっていることが多いとは思うけど、変えられない言語仕様を擁護するために文化を持ち出すという側面が感じられることもあるかな。
775(1): (ｱｳｱｳｳｰ Sa11-ut8q) 08/25(月)09:52 ID:oTWQEhGga(1/4) AAS
リスト内包が読み難いとか言ってる人は
Generatorとかどうしてるんだろうか
理解出来ないものは目に入らないタイプの人か
776: (ﾜｯﾁｮｲ be5c-ZAtR) 08/25(月)09:56 ID:srlPQ0qE0(1/5) AAS
失礼、print は例として適切じゃないね。単純な代入文に読み替えて。
777: (ｱｳｱｳｳｰ Sa11-ut8q) 08/25(月)09:57 ID:oTWQEhGga(2/4) AAS
lambda x: (print(x), x)[1]
778: (ﾜｯﾁｮｲ be5c-ZAtR) 08/25(月)10:00 ID:srlPQ0qE0(2/5) AAS
ジェネレーターはyieldで書けるから（強引）
ま、慣れるまで読みにくいと感じる人がいるのは分かるけどね。慣れてても「えーっと」ってなることあるし。
779: (ﾜｯﾁｮｲ ddec-hBFX) 08/25(月)10:06 ID:pqTCwzR00(1/2) AAS
>>774
Pythonコミュニティの文化って本質的には「そんなことより仕事しろ」であって、そう理解すると色々納得できるよ
言語を変えるよりしょうもない拘りを捨てた方が早い
780(1): (ｱｳｱｳｳｰ Sa11-ut8q) 08/25(月)10:15 ID:oTWQEhGga(3/4) AAS
代入したければ素直に__setattr__
781: (ﾜｯﾁｮｲ 6a40-hBFX) 08/25(月)11:03 ID:FnDhpDPk0(2/3) AAS
>>772
プログラムで仕事なんかしてねーし
782: (ﾜｯﾁｮｲ 6a40-hBFX) 08/25(月)11:06 ID:FnDhpDPk0(3/3) AAS
>>775
ジェネレータなんて別になんもおかしくなくね？
なんか初心者には難しそうと思った要素出してきたのか？w
783: (ﾜｯﾁｮｲ be5c-ZAtR) 08/25(月)11:11 ID:srlPQ0qE0(3/5) AAS
Pytnonのlambda周りの言語仕様が今さら変わるとも変えたいとも別に思ってはいないけれど、無名関数の本体には文を含められないというのは、言語仕様として中途半端で失敗だったんじゃないかなとは思っている。Pytnonはもう変わらないけれど、新たに設計される言語では（言語設計者が仮に同様に感じたなら）Pytnonの失敗を踏まえてうまく修正するんでしょ。高級言語というのはいわはシンタックスシュガーなんだからそういう点の評価・検証は大事。
ついでに言えば、Pytnonコミュニティの本質が、本当にこういう点をどうでもいいと考えているかもかなり疑問だけどね。少なくとも不満を持っている人がPytnonコミュニティの中にも少なからず居るからこそ、FAQで言い訳じみた説明をしているんじゃないかと思っているが。
式しか含められない中途半端な代物だけど、それである程度は何とかなるのでそれで間に合わせるてくれというのがPytnonコミュニティの文化だということならまぁそうかなと思う。ただ、それが本質的にどうでもいい問題で、そんなことは気にしないのがPytnonコミュニティの文化だと言われると、それは違うんじゃないのってなるかな。
>>780
素直ではないと思うけどw、lambdaでその場で書くというのを優先するならそういうことになっちゃうよね。
784: (ｱｳｱｳｳｰ Sa11-ut8q) 08/25(月)11:34 ID:oTWQEhGga(4/4) AAS
len(hoge) も糞仕様
785: (ﾜｯﾁｮｲ ad11-3/RT) 08/25(月)12:58 ID:CxzN3iJP0(2/3) AAS
最初は面食らうけど特殊メソッドで一般化できてる妙設計
糞だと思うなら代案どうぞ
786: (ｽﾌｯ Sdea-ut8q) 08/25(月)13:12 ID:yimvSMn3d(1) AAS
代案
hoge.__len__()
787: (ﾜｯﾁｮｲ be5c-ZAtR) 08/25(月)13:55 ID:srlPQ0qE0(4/5) AAS
__len__ は今でもあるから、代案ならhoge.lenみたいにメソッド形式で呼べるようにしたいという話なのでは？ Fluent Python のどこかのコラムに書いてあったけど、よく呼ばれるのでパフォーマンスを気にしたとか何とからしいけど。
788: (ﾜｯﾁｮｲ 29e1-M4AR) 08/25(月)15:47 ID:7aQuEbsn0(1) AAS
mapの糞さに比べたらlenなんて可愛いもんだ
789: (ﾜｯﾁｮｲ be15-ZAtR) 08/25(月)16:01 ID:srlPQ0qE0(5/5) AAS
たしかに使う機会は比較的少ないけれど、複数のiterableから並行的に要素を取得していくような場合にはジェネレーター式よりmapの方が便利じゃない？ zipだって特殊なmapなんだから、そんなに邪険に扱わなくても。
一番評判が悪いのは、文字列の連結のjoinだと思う。
790: (ﾜｯﾁｮｲ ade0-3/RT) 08/25(月)17:18 ID:CxzN3iJP0(3/3) AAS
mapレベルならジェネレータ式で書くけど
特殊な操作は明示的にmore-itertoolsつかうんで結局mapなスタイルは残るな
791: (ﾜｯﾁｮｲ 3e01-ChDN) 08/25(月)17:47 ID:d3/9MASU0(1) AAS
内包表記もlambdaも使うのはごく単純な処理でかつside-effect freeの場合だけ
特にlambdaは関数の引数としてインラインで書けるくらいシンプルじゃなければ基本使わない
個人的にはこれが基本原則だと思ってるけどlambdaのside-effectについて明記してるstyle guideないね
792(1): (ﾜｯﾁｮｲ 41e8-ZAtR) 08/25(月)19:04 ID:8weJ9FR00(2/2) AAS
一般論として副作用のない式の方が望ましいのはそうだろうけど、内包表記やlambdaについて、そういう一般論を超えて副作用を避けるべき固有の事情って何かあったっけ。
自分は内包表記では（たまにlambdaでも）結構長いコードになっちゃうことがあるな。別のところに書いて名前で参照する方が分かりやすくなるならもちろんそうするんだけど、結局ここにそのまま書いた方がまだマシかなとなることが結構ある。
793: (ﾜｯﾁｮｲ dd0f-hBFX) 08/25(月)20:04 ID:pqTCwzR00(2/2) AAS
>>792
内包表記や、lambda を引数に取るmapなどの関数は、本来的には実行順序に依存しない
副作用のある式を突っ込んでくるバカを想定するならその前提は破綻し、利用側の既存コードを破壊しないように関数の実装者は注意深く実行順序を維持しなければならなくなる
794(1): (ﾜｯﾁｮｲ 8610-ZAtR) 08/25(月)21:38 ID:a/zkXuf60(1) AAS
それは一般論の範囲内の話だし、そもそも高階関数の実装者側が注意深く実装すれば副作用の影響を回避できるというものでもないような。どんな副作用かも分からないんだし。
一般論として副作用を持つ式というのは可能な限り避けた方がいいよねというのは前提とした上で、たとえば自分以外がコードに手を入れることはないということが分かっているようなケースでも副作用を避けないといけない具体的な理由みたいなものがあるのかなというのが知りたかったんよ。
795: (ﾜｯﾁｮｲ bebd-hBFX) 08/25(月)23:52 ID:N2pfjYln0(1) AAS
>>794
一般論もクソも、副作用を考慮することで複雑性が高まることは自明であり、書くのが自分だけだろうと関係ない。
account.deposit(amount)
これが実はaccountはCatクラスのインスタンスで、depositは引数に応じた声色でスピーカーから鳴き声を鳴らすメソッドで、amountには声色を指定する文字列が入っている可能性は否定できないだろう？
accountとは本当に銀行口座なのか、実はディズニーランドではないのかなどと常に疑ってかからなければならない。
しかしお前は普段そんな心配はしていない。何故か？それはお前自身や周囲の人間がそこまでのバカではないとお前が信じているからだ。
同様に、lambdaに副作用書くバカは自分含めチームにいないと信じることにするなら、lambdaを見るたびにどんな副作用があるのか、同じ引数で2度呼び出されても問題ないのか、
といった余計な心配に脳のリソースを割く必要がなくなり、生産性が向上する。
796(3): (ﾜｯﾁｮｲ 8610-ZAtR) 08/26(火)07:53 ID:lpW4FrXI0(1) AAS
生産性の向上っていうのが誰視点なのかって話。
高階関数の実装者側は、そもそも渡される関数の副作用に対してできることは何もない（どんな副作用かも分からないんだから当然）のだから、元々「余計な心配にリソースを割く」こと自体がない。引数として渡される関数には副作用がないか、副作用を持つとしても高階関数の処理に影響は与えないという前提で書くだけでしょ。引数として副作用のあるlambdaを渡して、それが原因で高階関数の処理に影響を与えたら、それは呼び出し側が悪いってスタンスで書くしかない。
高階関数の呼び出し側は、特に高階関数のコードが読める状況なら（典型的には自分だけで書いている状況なら）、引数として渡す関数・lambdaに副作用があったとしても、それが高階関数の処理に影響を与えるか否かを判断できる。高階関数の処理に影響を与えない副作用がある関数・lambdaを与えるのは別に問題はないのではないか、それでも何か避けた方が良い固有の問題点があるのかどうかというのか792の疑問ね。
コードを読む人は、高階関数に引数として渡される関数・lambdaには副作用がないか、副作用を持つとしても高階関数の処理に影響は与えないという前提で読むだけ。
実際に副作用のあるlambdaを書くことはほとんどないけれど、780みたいな単純な代入処理はたまにlambdaで済ませたくなることもある。そういうときに、一般論とか教条主義的なスタンスを超えた問題が何があるのかなという疑問だったんだが。
797: (ﾜｯﾁｮｲ 6a1a-uCg5) 08/26(火)09:39 ID:tZRcIfkk0(1/2) AAS
>>796
他人とちゃんと話し合って決めろよ
798: (ﾜｯﾁｮｲ dd8d-hBFX) 08/26(火)09:58 ID:qtH/IdiV0(1) AAS
>>796
皆がお前のようにいちいち小難しいことを考えているわけではない、ってことだ。
一定以上のレベルのプログラマであればlambdaで副作用書いてるのを目にした時点で一般常識に照らして「こいつバカじゃないのか」という疑念を持つ。
お前のように細かいことを深く考えた上でやっているとは普通は思わない。
そしてバカを疑いながらのリーディングは通常よりも注意力を要し、結果的に時間がかかる、即ち可読性は低下する。
799: (ﾜｯﾁｮｲ 6a1a-uCg5) 08/26(火)10:13 ID:tZRcIfkk0(2/2) AAS
>>796 は仕事じゃないんだろうな
800: (ﾜｯﾁｮｲ a9f6-ut8q) 08/26(火)11:02 ID:GdDdRaCq0(1) AAS
800get
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 1.184s*