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