Pythonのお勉強 Part75 (896ﾚｽ)
上下前次1-新
1: (ﾜｯﾁｮｲ 33d8-PysV) 2025/04/04(金) 01:47:04.18 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
770: (ﾜｯﾁｮｲ 8610-ZAtR) 2025/08/24(日) 08:22:02.52 ID:+j+JozVj0(2/2)調 AAS
要素を表現する式やinの後が長大になることもしばしばあって、そういう場合はたしかに読みにくいんだけど、基本的にはすごい便利な構文だと思うけどなぁ。発想としては集合の内包表記っぽく書けるようにしようということなんだろうし、やっぱりHaskellは偉大だわ。
たとえばlist内包なら[ （要素を表す式） for （ループ変数・iterable変数） in （iterable） ] で、要素を表す式を書くのにループ変数・iterable変数を使うことができるというだけなので慣れればそんなに難しくないよ。キーワードのforとinが短くて埋没しやすいのが読みにくさを感じる原因なのかもしれない。
771(1): (ﾜｯﾁｮｲ 6aea-hBFX) 2025/08/25(月) 00:15:32.04 ID:FnDhpDPk0(1/3)調 AAS
慣れなんかな
巨大な行列が控えてる時の
そんでもなんか人間の認知と違う気がする
772(1): (ﾜｯﾁｮｲ 6a31-uCg5) 2025/08/25(月) 01:44:52.02 ID:cafSUUHh0(1)調 AAS
>>771
構文の話をするやつは道具の良し悪しばかりで論じて仕事はさっぱりできない人間
773: (ﾜｯﾁｮｲ adf5-3/RT) 2025/08/25(月) 03:06:00.70 ID:CxzN3iJP0(1/3)調 AAS
lambdaもだけど1行に複数の要素が入るととたんに可読性落ちるんで
そこは自制するのがクールという文化(Pythonic)
lambdaはdef、内包表記は複数行にするかforで書きなおす
774(1): (ﾜｯﾁｮｲ 41e8-ZAtR) 2025/08/25(月) 09:43:24.92 ID:8weJ9FR00(1/2)調 AAS
lambdaに文は入れられないが、文を含むような場合は名前あり関数として定義する方がわかりやすい……というのが一般論として常に正しいかは相当に疑問だけど。たとえば引数をそのままprintするようなごく単純なコードでも（lambdaにはできないので）名前あり関数にしなければいけないというのはかなりダルい。
Pytnonの文化は文化として尊重するし、実際、概ね妥当なアドバイスになっていることが多いとは思うけど、変えられない言語仕様を擁護するために文化を持ち出すという側面が感じられることもあるかな。
775(1): (ｱｳｱｳｳｰ Sa11-ut8q) 2025/08/25(月) 09:52:09.91 ID:oTWQEhGga(1/4)調 AAS
リスト内包が読み難いとか言ってる人は
Generatorとかどうしてるんだろうか
理解出来ないものは目に入らないタイプの人か
776: (ﾜｯﾁｮｲ be5c-ZAtR) 2025/08/25(月) 09:56:07.47 ID:srlPQ0qE0(1/5)調 AAS
失礼、print は例として適切じゃないね。単純な代入文に読み替えて。
777: (ｱｳｱｳｳｰ Sa11-ut8q) 2025/08/25(月) 09:57:57.26 ID:oTWQEhGga(2/4)調 AAS
lambda x: (print(x), x)[1]
778: (ﾜｯﾁｮｲ be5c-ZAtR) 2025/08/25(月) 10:00:20.80 ID:srlPQ0qE0(2/5)調 AAS
ジェネレーターはyieldで書けるから（強引）
ま、慣れるまで読みにくいと感じる人がいるのは分かるけどね。慣れてても「えーっと」ってなることあるし。
779: (ﾜｯﾁｮｲ ddec-hBFX) 2025/08/25(月) 10:06:45.19 ID:pqTCwzR00(1/2)調 AAS
>>774
Pythonコミュニティの文化って本質的には「そんなことより仕事しろ」であって、そう理解すると色々納得できるよ
言語を変えるよりしょうもない拘りを捨てた方が早い
780(1): (ｱｳｱｳｳｰ Sa11-ut8q) 2025/08/25(月) 10:15:14.12 ID:oTWQEhGga(3/4)調 AAS
代入したければ素直に__setattr__
781: (ﾜｯﾁｮｲ 6a40-hBFX) 2025/08/25(月) 11:03:28.46 ID:FnDhpDPk0(2/3)調 AAS
>>772
プログラムで仕事なんかしてねーし
782: (ﾜｯﾁｮｲ 6a40-hBFX) 2025/08/25(月) 11:06:33.88 ID:FnDhpDPk0(3/3)調 AAS
>>775
ジェネレータなんて別になんもおかしくなくね？
なんか初心者には難しそうと思った要素出してきたのか？w
783: (ﾜｯﾁｮｲ be5c-ZAtR) 2025/08/25(月) 11:11:08.09 ID:srlPQ0qE0(3/5)調 AAS
Pytnonのlambda周りの言語仕様が今さら変わるとも変えたいとも別に思ってはいないけれど、無名関数の本体には文を含められないというのは、言語仕様として中途半端で失敗だったんじゃないかなとは思っている。Pytnonはもう変わらないけれど、新たに設計される言語では（言語設計者が仮に同様に感じたなら）Pytnonの失敗を踏まえてうまく修正するんでしょ。高級言語というのはいわはシンタックスシュガーなんだからそういう点の評価・検証は大事。
ついでに言えば、Pytnonコミュニティの本質が、本当にこういう点をどうでもいいと考えているかもかなり疑問だけどね。少なくとも不満を持っている人がPytnonコミュニティの中にも少なからず居るからこそ、FAQで言い訳じみた説明をしているんじゃないかと思っているが。
式しか含められない中途半端な代物だけど、それである程度は何とかなるのでそれで間に合わせるてくれというのがPytnonコミュニティの文化だということならまぁそうかなと思う。ただ、それが本質的にどうでもいい問題で、そんなことは気にしないのがPytnonコミュニティの文化だと言われると、それは違うんじゃないのってなるかな。
>>780
素直ではないと思うけどw、lambdaでその場で書くというのを優先するならそういうことになっちゃうよね。
784: (ｱｳｱｳｳｰ Sa11-ut8q) 2025/08/25(月) 11:34:45.78 ID:oTWQEhGga(4/4)調 AAS
len(hoge) も糞仕様
785: (ﾜｯﾁｮｲ ad11-3/RT) 2025/08/25(月) 12:58:40.82 ID:CxzN3iJP0(2/3)調 AAS
最初は面食らうけど特殊メソッドで一般化できてる妙設計
糞だと思うなら代案どうぞ
786: (ｽﾌｯ Sdea-ut8q) 2025/08/25(月) 13:12:16.74 ID:yimvSMn3d(1)調 AAS
代案
hoge.__len__()
787: (ﾜｯﾁｮｲ be5c-ZAtR) 2025/08/25(月) 13:55:00.51 ID:srlPQ0qE0(4/5)調 AAS
__len__ は今でもあるから、代案ならhoge.lenみたいにメソッド形式で呼べるようにしたいという話なのでは？ Fluent Python のどこかのコラムに書いてあったけど、よく呼ばれるのでパフォーマンスを気にしたとか何とからしいけど。
788: (ﾜｯﾁｮｲ 29e1-M4AR) 2025/08/25(月) 15:47:13.68 ID:7aQuEbsn0(1)調 AAS
mapの糞さに比べたらlenなんて可愛いもんだ
789: (ﾜｯﾁｮｲ be15-ZAtR) 2025/08/25(月) 16:01:01.59 ID:srlPQ0qE0(5/5)調 AAS
たしかに使う機会は比較的少ないけれど、複数のiterableから並行的に要素を取得していくような場合にはジェネレーター式よりmapの方が便利じゃない？ zipだって特殊なmapなんだから、そんなに邪険に扱わなくても。
一番評判が悪いのは、文字列の連結のjoinだと思う。
790: (ﾜｯﾁｮｲ ade0-3/RT) 2025/08/25(月) 17:18:36.19 ID:CxzN3iJP0(3/3)調 AAS
mapレベルならジェネレータ式で書くけど
特殊な操作は明示的にmore-itertoolsつかうんで結局mapなスタイルは残るな
791: (ﾜｯﾁｮｲ 3e01-ChDN) 2025/08/25(月) 17:47:28.68 ID:d3/9MASU0(1)調 AAS
内包表記もlambdaも使うのはごく単純な処理でかつside-effect freeの場合だけ
特にlambdaは関数の引数としてインラインで書けるくらいシンプルじゃなければ基本使わない
個人的にはこれが基本原則だと思ってるけどlambdaのside-effectについて明記してるstyle guideないね
792(1): (ﾜｯﾁｮｲ 41e8-ZAtR) 2025/08/25(月) 19:04:08.96 ID:8weJ9FR00(2/2)調 AAS
一般論として副作用のない式の方が望ましいのはそうだろうけど、内包表記やlambdaについて、そういう一般論を超えて副作用を避けるべき固有の事情って何かあったっけ。
自分は内包表記では（たまにlambdaでも）結構長いコードになっちゃうことがあるな。別のところに書いて名前で参照する方が分かりやすくなるならもちろんそうするんだけど、結局ここにそのまま書いた方がまだマシかなとなることが結構ある。
793: (ﾜｯﾁｮｲ dd0f-hBFX) 2025/08/25(月) 20:04:04.19 ID:pqTCwzR00(2/2)調 AAS
>>792
内包表記や、lambda を引数に取るmapなどの関数は、本来的には実行順序に依存しない
副作用のある式を突っ込んでくるバカを想定するならその前提は破綻し、利用側の既存コードを破壊しないように関数の実装者は注意深く実行順序を維持しなければならなくなる
794(1): (ﾜｯﾁｮｲ 8610-ZAtR) 2025/08/25(月) 21:38:48.75 ID:a/zkXuf60(1)調 AAS
それは一般論の範囲内の話だし、そもそも高階関数の実装者側が注意深く実装すれば副作用の影響を回避できるというものでもないような。どんな副作用かも分からないんだし。
一般論として副作用を持つ式というのは可能な限り避けた方がいいよねというのは前提とした上で、たとえば自分以外がコードに手を入れることはないということが分かっているようなケースでも副作用を避けないといけない具体的な理由みたいなものがあるのかなというのが知りたかったんよ。
795: (ﾜｯﾁｮｲ bebd-hBFX) 2025/08/25(月) 23:52:22.89 ID:N2pfjYln0(1)調 AAS
>>794
一般論もクソも、副作用を考慮することで複雑性が高まることは自明であり、書くのが自分だけだろうと関係ない。
account.deposit(amount)
これが実はaccountはCatクラスのインスタンスで、depositは引数に応じた声色でスピーカーから鳴き声を鳴らすメソッドで、amountには声色を指定する文字列が入っている可能性は否定できないだろう？
accountとは本当に銀行口座なのか、実はディズニーランドではないのかなどと常に疑ってかからなければならない。
しかしお前は普段そんな心配はしていない。何故か？それはお前自身や周囲の人間がそこまでのバカではないとお前が信じているからだ。
同様に、lambdaに副作用書くバカは自分含めチームにいないと信じることにするなら、lambdaを見るたびにどんな副作用があるのか、同じ引数で2度呼び出されても問題ないのか、
といった余計な心配に脳のリソースを割く必要がなくなり、生産性が向上する。
796(3): (ﾜｯﾁｮｲ 8610-ZAtR) 2025/08/26(火) 07:53:15.97 ID:lpW4FrXI0(1)調 AAS
生産性の向上っていうのが誰視点なのかって話。
高階関数の実装者側は、そもそも渡される関数の副作用に対してできることは何もない（どんな副作用かも分からないんだから当然）のだから、元々「余計な心配にリソースを割く」こと自体がない。引数として渡される関数には副作用がないか、副作用を持つとしても高階関数の処理に影響は与えないという前提で書くだけでしょ。引数として副作用のあるlambdaを渡して、それが原因で高階関数の処理に影響を与えたら、それは呼び出し側が悪いってスタンスで書くしかない。
高階関数の呼び出し側は、特に高階関数のコードが読める状況なら（典型的には自分だけで書いている状況なら）、引数として渡す関数・lambdaに副作用があったとしても、それが高階関数の処理に影響を与えるか否かを判断できる。高階関数の処理に影響を与えない副作用がある関数・lambdaを与えるのは別に問題はないのではないか、それでも何か避けた方が良い固有の問題点があるのかどうかというのか792の疑問ね。
コードを読む人は、高階関数に引数として渡される関数・lambdaには副作用がないか、副作用を持つとしても高階関数の処理に影響は与えないという前提で読むだけ。
実際に副作用のあるlambdaを書くことはほとんどないけれど、780みたいな単純な代入処理はたまにlambdaで済ませたくなることもある。そういうときに、一般論とか教条主義的なスタンスを超えた問題が何があるのかなという疑問だったんだが。
797: (ﾜｯﾁｮｲ 6a1a-uCg5) 2025/08/26(火) 09:39:12.77 ID:tZRcIfkk0(1/2)調 AAS
>>796
他人とちゃんと話し合って決めろよ
798: (ﾜｯﾁｮｲ dd8d-hBFX) 2025/08/26(火) 09:58:03.54 ID:qtH/IdiV0(1)調 AAS
>>796
皆がお前のようにいちいち小難しいことを考えているわけではない、ってことだ。
一定以上のレベルのプログラマであればlambdaで副作用書いてるのを目にした時点で一般常識に照らして「こいつバカじゃないのか」という疑念を持つ。
お前のように細かいことを深く考えた上でやっているとは普通は思わない。
そしてバカを疑いながらのリーディングは通常よりも注意力を要し、結果的に時間がかかる、即ち可読性は低下する。
799: (ﾜｯﾁｮｲ 6a1a-uCg5) 2025/08/26(火) 10:13:17.81 ID:tZRcIfkk0(2/2)調 AAS
>>796 は仕事じゃないんだろうな
800: (ﾜｯﾁｮｲ a9f6-ut8q) 2025/08/26(火) 11:02:48.24 ID:GdDdRaCq0(1)調 AAS
800get
801: (ﾜｯﾁｮｲ 7954-IRdO) 2025/08/28(木) 07:37:52.10 ID:yOq6T87r0(1)調 AAS
デフォルト名前空間付きタグがどうやっても取得できない
802: (ﾜｯﾁｮｲ 29eb-ZAtR) 2025/08/29(金) 09:32:22.26 ID:sEZGPQSB0(1)調 AAS
dataclassは比較的新しいモジュールだけど、急速に普及した印象がある。namedtupleより分かりやすいので良い。
803(1): (ﾜｯﾁｮｲ 4ad1-Y9fL) 2025/08/30(土) 18:55:38.52 ID:hbOtSRYd0(1)調 AAS
goやrustみたいな最初から型がある言語のほうが良かったなぁ(´・ω・`)
804: (ﾜｯﾁｮｲ 7954-IRdO) 2025/08/30(土) 19:03:44.19 ID:qOwp6KvW0(1)調 AAS
むしろもっとperlみたいにゆるゆるな方が好み
805: (ﾜｯﾁｮｲ c6b3-ZAtR) 2025/08/30(土) 19:07:15.61 ID:9+bLWO6W0(1)調 AAS
パフォーマンスの点と他者の書くコードに型指定を強制できないという点は仕方ないけれど、それ以外は、型で実現したいことって概ねPytnonでもできるようになってない？ そうでもない？
806(1): (ﾜｯﾁｮｲ ca02-NWkk) 2025/08/30(土) 19:57:54.62 ID:Inltr+l10(1/2)調 AAS
>>803
型を明記しないと、パッと見でわからないよね
実行してデバッグしないと
807: (ﾜｯﾁｮｲ ca02-NWkk) 2025/08/30(土) 19:58:14.61 ID:Inltr+l10(2/2)調 AAS
>>806
ただ、
コンパイルしないのはラクだな
808: (ﾜｯﾁｮｲ feeb-VoZ8) 2025/08/30(土) 20:59:13.62 ID:LdU2fVxg0(1)調 AAS
Pythonが出てきた頃はPerl全盛だったけどCGIとかP言語はもう死語だろうな
809(3): (ﾜｯﾁｮｲ 132b-482X) 2025/08/31(日) 10:31:20.51 ID:GjhCFU0W0(1)調 AAS
python出てくる前はpython的な言語ってなんだたの？
lisp?
810: (ｱｳｱｳｳｰ Sae7-8tKF) 2025/08/31(日) 10:48:14.97 ID:8dn8jVHLa(1)調 AAS
当時から既に広く使われていて最もpython的と言うならTcl/Tkだよ
811: (ﾜｯﾁｮｲ 6f6c-O/rL) 2025/08/31(日) 20:58:12.37 ID:aib5LYmb0(1/5)調 AAS
>>809
シェルスクリプト
もしくは
rexx
812(1): (ﾜｯﾁｮｲ 6f76-P3Uo) 2025/08/31(日) 21:10:05.20 ID:yW7onUoP0(1)調 AAS
立ち位置的にはPerlでしょ
$とか%とかだりーなーとか思いつつ、ライブラリあるしみんな使ってるから使うかーって感じだった
今もオフサイドがとかうるせーなーとか思いつつ、結局Perlの時と同じでまあ言語なんかなんでもいいかに落ち着いて使ってる
813(1): (ﾜｯﾁｮｲ 738e-Uwoy) 2025/08/31(日) 21:34:01.42 ID:1n2Iv0Hx0(1)調 AAS
シェルスクリプトの代わりにはならんかったよ
初期導入されてたのってRedHatくらいだったし
Luaみたいな組み込み言語の側面はあったから
Tcl/Tkはしっくりくる
814: (ﾜｯﾁｮｲ a327-jRKo) 2025/08/31(日) 21:38:06.39 ID:Uf/mN+Cj0(1/4)調 AAS
>>809
シェルスクリプト
VBScript
815(2): (ﾜｯﾁｮｲ cfc5-O/rL) 2025/08/31(日) 21:38:24.47 ID:pHIfhBnQ0(1/3)調 AAS
awkだろにわかどもが
816: (ﾜｯﾁｮｲ a327-jRKo) 2025/08/31(日) 21:39:09.43 ID:Uf/mN+Cj0(2/4)調 AAS
Pythonの言語仕様はクソだが、とりあえず無償だったのでいろんな製品に採用されただけ。
817(2): (ﾜｯﾁｮｲ 6f6c-O/rL) 2025/08/31(日) 21:40:53.43 ID:aib5LYmb0(2/5)調 AAS
>>812
>>813
perlの前がなんだったかって話だぞ
わかってんのか？
ラリーウォール自体が話してるんだが
なんだこいつらキチガイか？
818(1): (ﾜｯﾁｮｲ a327-jRKo) 2025/08/31(日) 21:41:11.62 ID:Uf/mN+Cj0(3/4)調 AAS
>>815
それはシェルスクリプト内で使うもの
なんでもawkでやるやつは昔から嫌われている。
いまでもawkで作り込まれていてメンテナンスがたいへんな業務システムがえるわ。
819: (ﾜｯﾁｮｲ 6f6c-O/rL) 2025/08/31(日) 21:41:37.92 ID:aib5LYmb0(3/5)調 AAS
>>815
sed awk シェルスクリプトだな
ちゃんと書くと
820(1): (ﾜｯﾁｮｲ a327-jRKo) 2025/08/31(日) 21:43:14.03 ID:Uf/mN+Cj0(4/4)調 AAS
>>817
それならC言語だろうに
スクリプト言語だとシェルスクリプト
Pythonだって外部プログラムの呼び出しばかりでPython独自のライブラリは少ない。
821: (ﾜｯﾁｮｲ cfc5-O/rL) 2025/08/31(日) 21:46:31.03 ID:pHIfhBnQ0(2/3)調 AAS
>>818
Perlの前ってことは正しいだろ
822: (ﾜｯﾁｮｲ 3354-uCOC) 2025/08/31(日) 21:47:36.14 ID:F59m/DJE0(1/4)調 AAS
pythonが出てくる前の話なんだからperlだろ
perlの前はawk
823(3): (ﾜｯﾁｮｲ cfc5-O/rL) 2025/08/31(日) 21:59:07.78 ID:pHIfhBnQ0(3/3)調 AAS
Pythonの前だったわ
Asm->c/fortran->awk/sed/bash->perl->python->chatgpt/claude
が言語の歴史として正しいか
824: (ﾜｯﾁｮｲ 6f6c-O/rL) 2025/08/31(日) 22:07:25.17 ID:aib5LYmb0(4/5)調 AAS
>>820
ズレまくってるな
ここまで文脈わからないのが居るのこえー
825: (ﾜｯﾁｮｲ 6f6c-O/rL) 2025/08/31(日) 22:08:25.40 ID:aib5LYmb0(5/5)調 AAS
>>823
そう思う
826: (ﾜｯﾁｮｲ 3354-uCOC) 2025/08/31(日) 22:14:32.43 ID:F59m/DJE0(2/4)調 AAS
cからawkには行かない
お手軽スクリプト言語の系譜を辿っている
827: (ﾜｯﾁｮｲ 7381-iys5) 2025/08/31(日) 22:56:24.41 ID:/gVZuLVw0(1)調 AAS
>>823
馬鹿の代表例
828: (ﾜｯﾁｮｲ 3354-uCOC) 2025/08/31(日) 23:05:10.32 ID:F59m/DJE0(3/4)調 AAS
>>823の可読性の低さがやばい
829: (ﾜｯﾁｮｲ ff74-kaWg) 2025/08/31(日) 23:21:59.37 ID:BbjhEhoF0(1)調 AAS
Pythonを置き換えるのはどんな特徴を持った言語になるのかな。それともAI利用の広がりによって、プログラミング言語というもの自体があまり使われなくなったりするのか。
830: (ﾜｯﾁｮｲ 3354-uCOC) 2025/08/31(日) 23:50:54.85 ID:F59m/DJE0(4/4)調 AAS
もうテキストエディタで書くのは無理になるだろうな
概要設計や詳細設計や実装の各段階にAIが介入してきて、
オススメを提示してくる
それをそのまま使うかちょい修正して進めていくといつの間にか出来上がる
831: (ﾜｯﾁｮｲ a327-jRKo) 2025/09/01(月) 01:11:40.67 ID:E66qBEkG0(1)調 AAS
そもそもawkはシェルスクリプトでできないことを書くために作ったのにawkメインになるのは本来の使い方ではない。
自分がわかるものを多用するのは初心者にありがち。
bashも構文を拡張しすぎて、変なコードを書くやつがいて、こういう人間はawkも多用して、一貫性がないスクリプトを作る。
832: (ﾜｯﾁｮｲ 43cc-O/rL) 2025/09/01(月) 01:23:39.30 ID:jU4Yf7TF0(1)調 AAS
身の回りのことができればいいんだよ
833: (ﾜｯﾁｮｲ 3354-uCOC) 2025/09/01(月) 06:50:05.15 ID:yLzoixd30(1)調 AAS
ものすごい頑張ってる巨大batファイルとかよく見る
作れるのは判ったから、まともに書け
834: (ﾜｯﾁｮｲ 4347-ZyWg) 2025/09/01(月) 11:22:54.78 ID:ZXBt3uyf0(1)調 AAS
文法はBASICでいい
835: (ﾗｸｯﾍﾟﾍﾟ MM7f-XnkP) 2025/09/01(月) 12:31:51.79 ID:/Y8xWjD9M(1)調 AAS
OPEN "TEST.DAT" FOR INPUT AS #1
836: (ﾜｯﾁｮｲ 4379-yzHn) 2025/09/01(月) 15:52:53.01 ID:3nUHTtao0(1)調 AAS
perlは、個人的にはsedやawkのより使いやすい代用品だなぁ
単独でというより、シェルスクリプトでコマンドとして使うことが多い
837: (ﾜｯﾁｮｲ a323-Uwoy) 2025/09/01(月) 16:15:49.04 ID:BP0v7SMQ0(1)調 AAS
起動時間やメモリ消費が問題になることはほぼないしな
perl/rubyで簡潔に書けることをsed/awkでコネコネしてると泣けてくる
838: (ﾌﾞｰｲﾓ MM7f-jRKo) 2025/09/01(月) 16:21:42.55 ID:PK9JSPJ+M(1)調 AAS
60代がいるなw
839(1): (ﾜｯﾁｮｲ 73f6-8tKF) 2025/09/02(火) 11:36:27.12 ID:/Zmper4S0(1)調 AAS
>>809
>python出てくる前はpython的な言語ってなんだたの？
>>817
>perlの前がなんだったかって話だぞ
どっちやねん
840: (ﾜｯﾁｮｲ ff67-O/rL) 2025/09/02(火) 14:12:33.11 ID:kizKvhm30(1)調 AAS
>>839
関西弁アホすぎ
朝鮮人か？
バカリズム朝鮮人並みに馬鹿だな
841: (ﾜｯﾁｮｲ ff2a-0vxd) 2025/09/02(火) 18:09:20.95 ID:v1mKUBov0(1)調 AAS
なんでやねん
842: (ﾜｯﾁｮｲ 6f8c-kST1) 2025/09/02(火) 18:39:38.26 ID:f8uf/zR40(1)調 AAS
せやせや！
843: (ﾜｯﾁｮｲ 4301-gtKn) 2025/09/02(火) 19:15:32.06 ID:i1waRe/20(1)調 AAS
In the face of ambiguity, refuse the temptation to guess.
844: (ﾜｯﾁｮｲ 1342-49dw) 2025/09/02(火) 20:59:02.02 ID:UyC0HX6M0(1)調 AAS
せやかて工藤
845: (ﾜｯﾁｮｲ cf10-kaWg) 2025/09/03(水) 08:24:59.13 ID:Yiqf6tZF0(1)調 AAS
Pytnonは習得しやすい言語という立ち位置だし、それは実際にもそうだと思うけど、言語仕様は、全体としては結構大きくなっちゃっていて、シンプルな言語とはちょっと言いにくい感じになっているかな。
なくても何とかなるけどあると利便性が向上する機能（パッと思いつくものとしてはf-stringとかmatch文とか）が増えてくるとそういう印象になるのかも。
846: (JP 0Hdf-8tKF) 2025/09/03(水) 14:54:55.86 ID:eTDtbpqFH(1)調 AAS
さてはlisperだな
847: (ﾜｯﾁｮｲ 43cc-482X) 2025/09/04(木) 00:57:22.22 ID:UisKbpz40(1)調 AAS
bashの文字列操作で凝ったことすると可読性最悪になるからそこでpython使うと分かりやすすぎて感動した
848: 普天率土 (ﾜｯﾁｮｲ 7333-n2sn) 2025/09/04(木) 14:39:36.17 ID:gEToyzrn0(1)調 AAS
Pythonまったく使ったことなくて
5ｃｈのスレタイ読み上げラジオをAIで作ったら3000行超えたわ
そこで初めてAIに分割して作るもんだと教わった
849: (ﾜｯﾁｮｲ 7a1c-aJ3f) 2025/09/10(水) 20:25:10.65 ID:zlwQrrhf0(1)調 AAS
あるプログラムの出力結果の変数を構造保ったままテキストでダンプして出力しようとしてるけど難しいんだな
perlならdata::dumperで一発なんだけどな
850: (ﾜｯﾁｮｲ 9a02-MPWR) 2025/09/10(水) 20:30:53.90 ID:u3op23Y70(1)調 AAS
コンパイルしなくて便利な分、
パット見でオブジェクトとか変数の型がわからないから、
ガッツリのプログラムは大変だね…
851: (ﾜｯﾁｮｲ a36d-5o5I) 2025/09/10(水) 22:08:59.42 ID:AoAHRWDo0(1)調 AAS
PyYAMLは？
カスタムタグでクラスも扱える
852(1): (ﾜｯﾁｮｲ 7a1c-aJ3f) 2025/09/11(木) 02:01:55.28 ID:8aE/TL8t0(1)調 AAS
ありがとう
量子コンピューティングSDK:qiskitで実機の戻り調べてるんだけど
やっぱり変数の型調べながら一つずつ開いていくしかないっぽいね
バイナリの中までは調べないけどさ
っていうかperlのData::Dumperの動きの方が特例的にやばい感じで異常なんだな
まさにperlって感じ
853: (ﾜｯﾁｮｲ df95-6P5Z) 2025/09/11(木) 04:47:38.61 ID:ntfz+n6+0(1)調 AAS
pythonでcpu並列とGPU並列をまなびたいです。
おすすめのサイトありますか？
854: (ｽﾌｯ Sdba-bj1o) 2025/09/11(木) 10:07:43.70 ID:3rL2CEwSd(1)調 AAS
構造調べたいだけなら
pprint.pprint(hoge)
855: (ﾜｯﾁｮｲ 9ab4-aFDf) 2025/09/11(木) 18:16:56.99 ID:XtPwu2Bi0(1)調 AAS
>>852
Gist に Perl の Data.Dumper を Python に移植したものがあった (MIT ライセンス)
外部ﾘﾝｸ:gist.github.com
これでいけそう?
856: (ﾜｯﾁｮｲ b393-mKxa) 2025/09/12(金) 19:31:26.73 ID:13rTt+Ea0(1)調 AAS
Pythonでサーバーサイド作ろうかと思ったけど遅いかな
ほかの言語にしたほうがいいかな
857(1): (ﾜｯﾁｮｲ 8a9f-snD5) 2025/09/13(土) 13:34:43.94 ID:DCq23AIZ0(1)調 AAS
気になるならPyPyとかあるけど
Webアプリなら待ち時間がほとんどだから書きやすさ重視
じゃないと速度重視なAIのフロントエンドにつかわれてない
858: (ﾜｯﾁｮｲ 5ff2-O3fR) 2025/09/13(土) 20:28:10.78 ID:8jhWe9D50(1)調 AAS
>>857
なるへそね
まあ速度がクリティカルじゃなければ気にしなくていいよね
859: (ﾜｯﾁｮｲ 3fb6-mPtt) 2025/09/14(日) 19:55:23.96 ID:ithLDxGz0(1)調 AAS
PYTHON！
「ドッペルゲンガー（極端なそっくりさん）」を調べたら赤の他人なのにDNAが似ていた
2025.09.14 SUN
外部ﾘﾝｸ:nazology.kusuguru.co.jp
ADHDの脳は実際に普通の人とは構造が異なっていた
2025.09.14 SUN
外部ﾘﾝｸ:nazology.kusuguru.co.jp
>>各研究で用いられていたMRI（磁気共鳴画像）装置や画像の解析方法に“微妙な違い”があり、その影響が十分に補正できていなかったためです。この問題は以前から専門家の間でも指摘されていましたが、長年、解決が難しいまま残されていました。
>>この問題に対して、千葉大学（Chiba University）、大阪大学（Osaka University）、福井大学（University of Fukui）など国内複数の大学による共同研究チーム（代表：水野義史〈Yoshifumi Mizuno〉准教授）は、実際に複数の装置で同じ被験者を測定してそのズレを正確に補正する「TS法」と呼ばれる手法を本格的に導入し、長年の課題だった技術的ノイズを徹底的に排除しました。
>>その結果、ADHDの子どもたちの脳にどんな“違い”があるのかを、これまでになく明確に示すことに成功したという。
>>これは理屈としてはばらつきを補正する非常に優れた方法ですが、実際には大規模な協力体制と多くの技術的・資金的なサポートが必要となるため、これまで本格的に実施されることはありませんでした。
>>研究グループはこうして、ADHDの子どもとそうでない子ども、計294名（ADHDの子ども116名、定型発達（健常）児178名）の脳画像を比較しました。ここでは、年齢や性別、知能指数（IQ）などの違いも統計的にしっかり調整されています。
>>結果、ADHDの子どもたちの脳には、実際につくりの違いがあることがはっきり示されました。
◇全精神病や知的障碍者も該当しているでしょう！
まるで45億年前の太陽系!? “惑星の誕生”が初めて観測される
2025.09.13
外部ﾘﾝｸ:wired.jp
脳から直接脳波を読み取り意思疎通 ALS患者などの生活の助けに 埋め込み型BCI装置開発 2028年の実用化に向けて年内の治験申請を目指す
9/14(日) 9:00
外部ﾘﾝｸ:news.yahoo.co.jp
860: (ﾜｯﾁｮｲ 8f1f-42/7) 2025/09/14(日) 20:14:35.23 ID:EbV68LBT0(1)調 AAS
スレチ
861: (ｱｳｱｳｳｰ Sa53-ilUi) 2025/09/14(日) 20:28:17.08 ID:uqktGAy2a(1)調 AAS
まるちんこ
862(2): (ﾜｯﾁｮｲ ff02-LMNA) 2025/09/19(金) 12:09:51.27 ID:qGqvKNvA0(1)調 AAS
awkで以下のように連想配列を使ってます
BEGIN {
arr["id1"] = "val1";
arr["id2"] = "val2";
printf(arr["id2"]);
}
→結果は「val2」
また、以下のようなid列、val列のCSVファイルがあります
id1,val1
id2,val2
これらのものを使い、Pythonでも同様に、idが指定した値に合致するval列を取得したいと思ってます
以下のようにcsv.DictReaderを使ってディクショナリに読み込んでみることはできました
with open('data/data.csv', 'r') as file:
d = list(csv.DictReader(file, fieldnames=['id', 'val']))
このリストを列挙して中身を表示する等はできたのですが、
指定したidに合致するval列を取得する方法が分かりません
よい方法を教えてください
863: (ﾍﾞｰｲﾓ MM8f-xxKh) 2025/09/19(金) 12:24:49.40 ID:4hZSGpQJM(1)調 AAS
>>862
1. そのレスを丸ごとコピーします
2. ChatGPTやClaude等のAIの入力欄に貼り付けます
3. メッセージを送信します
4. (ﾟдﾟ)
864: (ﾜｯﾁｮｲ 3f32-yasC) 2025/09/19(金) 12:53:34.42 ID:jazVqD/P0(1)調 AAS
ありがとうございます！！
865(1): (ﾜｯﾁｮｲ 8ff0-0uML) 2025/09/19(金) 13:17:33.03 ID:2/pebCZF0(1)調 AAS
d['id1'] で 'val1' を参照できるようにしたいということなら、各行ごとに1つのdict にするんじゃなくて、全体を1つのdict にする方がいいのでは。 d = { id: val for id, val in csv.reader( file ) } とかは？
866(1): (ｽﾌｯ Sd5f-ilUi) 2025/09/19(金) 13:47:25.33 ID:tcJc82E7d(1)調 AAS
with open('data/data.csv', 'r') as file:
d = csv.DictReader(file, fieldnames=['id', 'val'])
print(d['idHOGE'])
867: (ﾜｯﾁｮｲ 4f01-hzaU) 2025/09/19(金) 16:26:18.90 ID:vOzhAdtP0(1)調 AAS
今はChatGPTでも重複時はどうしますか？ってちゃんと確認してくるんだな
出てくるコードの質はともかく要点はほぼ全部網羅してくれてめちゃ親切
868: (ﾜｯﾁｮｲ 7f36-IHfe) 2025/09/19(金) 18:19:29.27 ID:7aePTcRM0(1)調 AAS
chatGPTにプログラムの質問をするときは必ずThinkingモードにすること
デフォルト設定だとThinkingしないクソコード出してくることが多い
869: (ｱｳｱｳｳｰ Sa53-ilUi) 2025/09/19(金) 19:23:31.74 ID:hOahK7C8a(1)調 AAS
ちっとは考えろやバカタレ
870: (ﾜｯﾁｮｲ 3f02-VRQG) 2025/09/20(土) 18:48:36.37 ID:usmEJHWE0(1)調 AAS
Visual Studio Codeの変数ウォッチウィンドウが見づらいわ
他にないのかね？
871(1): (ﾜｯﾁｮｲ 8ffc-tBek) 2025/09/20(土) 19:05:33.94 ID:FzwQ5fID0(1)調 AAS
現状VSCodeかPyCharmの二択だからPyCharmかな試すなら
やりたいことによってはJupyterが最強の場合もある
872: (ﾜｯﾁｮｲ 0602-faWY) 2025/09/21(日) 10:32:13.35 ID:oeEC4MB10(1)調 AAS
>>865
>>866
回答どうもです
いろいろと見直し、全体を1つのdictにする、という方針として、以下のようにしました
awkの連想配列とPythonの辞書の違いを再認識しました
with open('data/data.csv', 'r') as file:
d = csv.DictReader(file, fieldnames=['id', 'val'])
result = {row['id']: row['val'] for row in d}
print(result['id2'])
→val2が得られる
873: (ﾜｯﾁｮｲ 0601-WLcO) 2025/09/21(日) 12:52:45.41 ID:wuI8+BKP0(1)調 AAS
id重複時に黙って後勝ちになるが望ましいかどうか
874(1): (ﾜｯﾁｮｲ 6a04-lG8I) 2025/09/21(日) 13:04:55.71 ID:ttcu4MUo0(1/2)調 AAS
そんなことはどうでもいいだろうよ
責任の所在の話したってしょうがないでしょ
875: (ﾜｯﾁｮｲ 8a02-CSnM) 2025/09/21(日) 14:22:55.90 ID:RnLJIZeo0(1)調 AAS
>>871
まあ、PyCharmも似たようなもんだね…
業務レベルなので、Jupyterは無理かな…
876: (ﾜｯﾁｮｲ 3bf6-4qXD) 2025/09/21(日) 14:41:37.65 ID:KUfqxhia0(1/3)調 AAS
awkのことはよく知らないが、連想配列でキーの重複があるの？
877(1): (ﾜｯﾁｮｲ 6f54-vMDn) 2025/09/21(日) 15:03:09.09 ID:TKqe4uhF0(1/2)調 AAS
あんなのはハッシュだしな
どうやって衝突回避してるのか謎だった
今も謎
878(2): (ﾜｯﾁｮｲ 9301-xzLD) 2025/09/21(日) 15:34:44.26 ID:kS1Ctw9y0(1/2)調 AAS
>>874
外部ファイルから読み込むのに重複時の振る舞いがどうでもいい場合なんてある？
仮に後勝ちは望ましくないがチェック処理を入れるくらいならサイレントにバグるので問題ないケースだとしてもそういう確認とか意思決定は明示的にしないといけないんじゃない
879: (ﾜｯﾁｮｲ 9301-xzLD) 2025/09/21(日) 15:37:03.95 ID:kS1Ctw9y0(2/2)調 AAS
>>877
ハッシュの衝突を回避してるわけじゃなくて衝突してもいいような構造にしてるだけ
その代わり衝突が増えるにつれ性能が悪化していく
880(1): (ﾜｯﾁｮｲ 3bf6-4qXD) 2025/09/21(日) 15:54:55.42 ID:KUfqxhia0(2/3)調 AAS
862を読む限り、csvファイルのキー列の値のユニーク性は前提になっていると思うんだが。だから連想配列とかdictに入れるって想定なんじゃないの？
881(1): (ﾜｯﾁｮｲ 6a04-lG8I) 2025/09/21(日) 15:59:04.32 ID:ttcu4MUo0(2/2)調 AAS
>>878
データの操作とデータ構造の検査は切り分けることが出来る話でしょ
質問はデータ操作なんだからそっちにフォーカスすればいい
IDなんて名前なんだから作成元が非重複を保証してんのかもしれんし、貰い手側が質問の処理の前段でなんかチェックさせてもいい
いずれにしてもこの質問では考慮する必要のないかつ混同する必要のない事柄ってこと
882(1): (ﾜｯﾁｮｲ 732a-ljyC) 2025/09/21(日) 16:40:42.51 ID:e5nOC9aY0(1)調 AAS
>>878
> 外部ファイルから読み込むのに重複時の振る舞いがどうでもいい場合なんてある？
ログファイルを読み、とある項目の最新内容が欲しい場合とか。
883(1): (ﾜｯﾁｮｲ 8701-xzLD) 2025/09/21(日) 17:30:15.23 ID:7OCfaZ6W0(1)調 AAS
>>881
俺は分けることができるとも分けたほうがいいとも思わないから考え方の違いだね
チェックを入れると内包表記を使わないほうがよくなる可能性が高かったりするわけでデータ操作と呼んでるところの内容が変わってくる
>>880
ユニークが前提となっているからどうでもよいじゃなくて「ユニークが前提なので万が一重複が来た時は後勝ちで問題ない」というところまで明確に判断しておいたほうがいいんじゃないのという話
>>882
それはどうでもいい場合じゃなくてログを読む方向に合わせて後勝ちか先勝ちかどちらか一方に仕様を決めなければいけない場合だと思う
884: (ﾜｯﾁｮｲ 6f54-vMDn) 2025/09/21(日) 17:58:13.74 ID:TKqe4uhF0(2/2)調 AAS
何かの関数の戻り値を渡す、みたいに動作が決まってたら決め打ちでいいけど、
ファイルや通信なんか何でもありなので、
そもそも開けない、通信できない、から始まって、間違いまくったデータでもちゃんと動かないと
885(2): (ﾜｯﾁｮｲ 3bf6-4qXD) 2025/09/21(日) 19:55:43.86 ID:KUfqxhia0(3/3)調 AAS
>>883
ユニーク性が前提となっていることを明確にしておくのはいいことだけど、ユニーク性を前提として設計しているにも拘らず「万一重複が来た」らそれ自体大問題だと思うけど。それは想定していた前提が成立していないということでしょ。そもそも862のようにid値を検索キーとして使う場合で「後勝ちで問題ない」場合なんてあるかな？
重複がないということを前提にできるからこそdictを使っているのであって、前提が変わってくるならデータ構造の選択とかも変わってくると思うけど。一般論としてデータに重複があっても問題がない場合かどうか気をつけようということなら素直に頷けるんだけど、862のケースで主張するのはムリがあると思うよ。
886: (ｱｳｱｳｳｰ Sacf-kv3/) 2025/09/21(日) 19:56:22.43 ID:kxRRh56Ha(1)調 AAS
うましかいないよな
887: (ﾜｯﾁｮｲ 8eaf-wBym) 2025/09/21(日) 20:54:40.37 ID:ORrZGGDb0(1)調 AAS
外部ﾘﾝｸ[htm]:mannersy.co.jp
888: (ﾜｯﾁｮｲ 2e01-xzLD) 2025/09/21(日) 23:42:10.87 ID:4W4Jokme0(1)調 AAS
>>885
個人的にはソフトウェアの設計は想定している前提が成立していない場合の対応まで決めるものだと思ってるけど、今回のはそんな大げさな話じゃないよね
後勝ちになる実装を採用してることを自覚してそれで問題ないと判断できてるかどうか
889(1): (ﾜｯﾁｮｲ 1e10-4qXD) 2025/09/22(月) 00:15:54.16 ID:scIzhboY0(1/2)調 AAS
重複がありうる状況なら、後勝ちで上書きしてしまう仕様で問題ないわけないだろ。862みたいに検索キーとして使っている場合に。誰がそんな状況でdictを使うんだよ、あほか。
890: (ﾜｯﾁｮｲ 2e01-xzLD) 2025/09/22(月) 00:42:13.25 ID:nbJbLtLI0(1/2)調 AAS
>>889
上で出てきたログの例を理解できない？
後勝ちでいい例なんていくらでもあると思うんだが
891: (ﾜｯﾁｮｲ 1e10-4qXD) 2025/09/22(月) 01:23:57.89 ID:scIzhboY0(2/2)調 AAS
あのさ、>>862をもう一回読んできたら？ 「idが指定した値に合致するval列を取得したい」って書いてあるだろ？
idに重複があったら、val列の値の中に参照できないものが出てきてしまうわけだけど、それを許容している状況設定だと本気で思うのか？
892: (ﾜｯﾁｮｲ 2e01-xzLD) 2025/09/22(月) 01:41:53.66 ID:nbJbLtLI0(2/2)調 AAS
>>885
「862のようにid値を検索キーとして使う場合」とか「862みたいに検索キーとして使っている場合」って書いてたら「id値を検索キーとして使う場合」のジェネラルな話をしてるのかと思うじゃん普通？
862に限定した話ならそりゃ重複時に上書きが望ましい可能性は低そうだと思うよ
だからこそ問題提起したわけで
ただ「望ましい」と「問題ない」は同じではなくて単純上書き以外の実装をする価値がないくらいに重複の可能性が低いなら望ましくなくても上書きする実装でも問題ないという判断もありえるよね
結局自覚して意思決定できてるかどうか
893(2): (ﾜｯﾁｮｲ 23ad-0Qkb) 2025/09/24(水) 00:35:54.59 ID:q1Q2Yb580(1)調 AAS
そもそも awkの例を出してきた人が、連想配列の重複を考慮していないのに
それを python で ってやったから、おかしくなっているとしか
中途半端に、awk を出した結果
894: (ﾜｯﾁｮｲ 0a8f-p2ny) 2025/09/24(水) 04:40:12.99 ID:bD0tkg1v0(1)調 AAS
原子をナノチューブへ一列に閉じ込めた「一次元気体」の撮影に成功！
2025.09.23
外部ﾘﾝｸ:nazology.kusuguru.co.jp
>>あるクリプトン原子（Kr）をカーボンナノチューブの内部に閉じ込めることで「一次元の気体」を作成し、その様子をリアルタイムで視覚的に捉えることに成功しました。
>>実際に撮影された映像では、クリプトン原子が狭いチューブ内である種の「交通渋滞」に巻き込まれており、数珠つなぎに配置されている様子が見て取れます。
>>強度が高くて軽量、また電気を良く通す特性を持つことから、次世代の電子機器や新材料の開発において中心的な役割を果たしています。
>>>また近年ではカーボンナノチューブの内部に原子や分子を詰め込むことで、新しい機能を持つ素材の開発が進められています。
固体と液体の両方の性質を持つ水を観測することに成功！
公開日2025.09.23 18:00:02 TUESDAY
外部ﾘﾝｸ:nazology.kusuguru.co.jp
※液体と気体の両方を持っている者も撮影できるのでは？
※燃える氷と呼ばれるものががあるので個体と液体の両方を持っている者も撮影できるのでは
史上最も古いブラックホールを観測、133億年前
2025.09.23
外部ﾘﾝｸ:nazology.kusuguru.co.jp
ビッグバン以前の宇宙に新説――重力波が宇宙を紡いだ可能性
2025.09.23
外部ﾘﾝｸ:nazology.kusuguru.co.jp
>>従来の宇宙誕生過程では宇宙が始まった直後の急激な膨張を説明するために「インフラトン」と呼ばれる謎のエネルギーが仮定されてきました。
>>しかし今回の研究は、こうした未知のエネルギーに頼らず、私たちがすでに観測している量子と重力だけでだけで宇宙の構造（銀河や星の元になる密度のムラ）が作られた可能性を示しています。
>>この画期的な提案は、宇宙論の理論モデルを大きく変える可能性を秘めており、今後の宇宙観測でその正しさを確認できると期待されています。
895: (ﾜｯﾁｮｲ 872a-SUnJ) 2025/09/24(水) 04:42:18.51 ID:3bDRa/7F0(1)調 AAS
>>893
> そもそも awkの例を出してきた人が、連想配列の重複を考慮していない
それは空想。考慮したか否かは余人の与り知らぬところ。
896: (ﾜｯﾁｮｲ 2e01-Fjhn) 2025/09/24(水) 13:15:04.93 ID:ZY5d1Pcc0(1)調 AAS
>>893
awkは関係ない
リストを辞書に変換する処理を実装する際は
例外的な状況を除いて重複ケースを考慮するのは必須
入力が外部ファイルならなおさら
重複ケースを考慮した上でどういう実装を選択するかは
考慮する/しないかとはまた別の判断
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.031s