Pythonのお勉強 Part75

2025/04/04(金) 01:47:04.18

!extend:default:vvvvv:1000:1024
!extend:default:vvvvv:1000:1024

↑スレ立てる毎に減るので、減ってたら３つに補充すること。

※前スレ
Pythonのお勉強 Part74
https://mevius.5ch.net/test/read.cgi/tech/1726881242/
VIPQ2_EXTDAT: default:vvvvv:1000:512:: EXT was configured

VIPQ2_EXTDAT: default:vvvvv:1000:512:: EXT was configured

2025/08/25(月) 20:04:04.19

>>792
内包表記や、lambda を引数に取るmapなどの関数は、本来的には実行順序に依存しない
副作用のある式を突っ込んでくるバカを想定するならその前提は破綻し、利用側の既存コードを破壊しないように関数の実装者は注意深く実行順序を維持しなければならなくなる

2025/08/25(月) 21:38:48.75

それは一般論の範囲内の話だし、そもそも高階関数の実装者側が注意深く実装すれば副作用の影響を回避できるというものでもないような。どんな副作用かも分からないんだし。
一般論として副作用を持つ式というのは可能な限り避けた方がいいよねというのは前提とした上で、たとえば自分以外がコードに手を入れることはないということが分かっているようなケースでも副作用を避けないといけない具体的な理由みたいなものがあるのかなというのが知りたかったんよ。

2025/08/25(月) 23:52:22.89

>>794
一般論もクソも、副作用を考慮することで複雑性が高まることは自明であり、書くのが自分だけだろうと関係ない。
account.deposit(amount)
これが実はaccountはCatクラスのインスタンスで、depositは引数に応じた声色でスピーカーから鳴き声を鳴らすメソッドで、amountには声色を指定する文字列が入っている可能性は否定できないだろう？
accountとは本当に銀行口座なのか、実はディズニーランドではないのかなどと常に疑ってかからなければならない。
しかしお前は普段そんな心配はしていない。何故か？それはお前自身や周囲の人間がそこまでのバカではないとお前が信じているからだ。
同様に、lambdaに副作用書くバカは自分含めチームにいないと信じることにするなら、lambdaを見るたびにどんな副作用があるのか、同じ引数で2度呼び出されても問題ないのか、
といった余計な心配に脳のリソースを割く必要がなくなり、生産性が向上する。

2025/08/26(火) 07:53:15.97

生産性の向上っていうのが誰視点なのかって話。
高階関数の実装者側は、そもそも渡される関数の副作用に対してできることは何もない（どんな副作用かも分からないんだから当然）のだから、元々「余計な心配にリソースを割く」こと自体がない。引数として渡される関数には副作用がないか、副作用を持つとしても高階関数の処理に影響は与えないという前提で書くだけでしょ。引数として副作用のあるlambdaを渡して、それが原因で高階関数の処理に影響を与えたら、それは呼び出し側が悪いってスタンスで書くしかない。
高階関数の呼び出し側は、特に高階関数のコードが読める状況なら（典型的には自分だけで書いている状況なら）、引数として渡す関数・lambdaに副作用があったとしても、それが高階関数の処理に影響を与えるか否かを判断できる。高階関数の処理に影響を与えない副作用がある関数・lambdaを与えるのは別に問題はないのではないか、それでも何か避けた方が良い固有の問題点があるのかどうかというのか792の疑問ね。
コードを読む人は、高階関数に引数として渡される関数・lambdaには副作用がないか、副作用を持つとしても高階関数の処理に影響は与えないという前提で読むだけ。

実際に副作用のあるlambdaを書くことはほとんどないけれど、780みたいな単純な代入処理はたまにlambdaで済ませたくなることもある。そういうときに、一般論とか教条主義的なスタンスを超えた問題が何があるのかなという疑問だったんだが。

2025/08/26(火) 09:39:12.77

>>796
他人とちゃんと話し合って決めろよ

2025/08/26(火) 09:58:03.54

>>796
皆がお前のようにいちいち小難しいことを考えているわけではない、ってことだ。
一定以上のレベルのプログラマであればlambdaで副作用書いてるのを目にした時点で一般常識に照らして「こいつバカじゃないのか」という疑念を持つ。
お前のように細かいことを深く考えた上でやっているとは普通は思わない。
そしてバカを疑いながらのリーディングは通常よりも注意力を要し、結果的に時間がかかる、即ち可読性は低下する。

2025/08/26(火) 10:13:17.81

>>796 は仕事じゃないんだろうな

2025/08/26(火) 11:02:48.24

800get

2025/08/28(木) 07:37:52.10

デフォルト名前空間付きタグがどうやっても取得できない

2025/08/29(金) 09:32:22.26

dataclassは比較的新しいモジュールだけど、急速に普及した印象がある。namedtupleより分かりやすいので良い。

2025/08/30(土) 18:55:38.52

goやrustみたいな最初から型がある言語のほうが良かったなぁ(´・ω・`)

2025/08/30(土) 19:03:44.19

むしろもっとperlみたいにゆるゆるな方が好み

2025/08/30(土) 19:07:15.61

パフォーマンスの点と他者の書くコードに型指定を強制できないという点は仕方ないけれど、それ以外は、型で実現したいことって概ねPytnonでもできるようになってない？　そうでもない？

2025/08/30(土) 19:57:54.62

>>803
型を明記しないと、パッと見でわからないよね
実行してデバッグしないと

2025/08/30(土) 19:58:14.61

>>806
ただ、
コンパイルしないのはラクだな

2025/08/30(土) 20:59:13.62

Pythonが出てきた頃はPerl全盛だったけどCGIとかP言語はもう死語だろうな

2025/08/31(日) 10:31:20.51

python出てくる前はpython的な言語ってなんだたの？
lisp?

2025/08/31(日) 10:48:14.97

当時から既に広く使われていて最もpython的と言うならTcl/Tkだよ

2025/08/31(日) 20:58:12.37

>>809
シェルスクリプト
もしくは
rexx

2025/08/31(日) 21:10:05.20

立ち位置的にはPerlでしょ
$とか%とかだりーなーとか思いつつ、ライブラリあるしみんな使ってるから使うかーって感じだった
今もオフサイドがとかうるせーなーとか思いつつ、結局Perlの時と同じでまあ言語なんかなんでもいいかに落ち着いて使ってる

2025/08/31(日) 21:34:01.42

シェルスクリプトの代わりにはならんかったよ
初期導入されてたのってRedHatくらいだったし
Luaみたいな組み込み言語の側面はあったから
Tcl/Tkはしっくりくる

2025/08/31(日) 21:38:06.39

>>809
シェルスクリプト
VBScript

2025/08/31(日) 21:38:24.47

awkだろにわかどもが

2025/08/31(日) 21:39:09.43

Pythonの言語仕様はクソだが、とりあえず無償だったのでいろんな製品に採用されただけ。

2025/08/31(日) 21:40:53.43

>>812
>>813
perlの前がなんだったかって話だぞ
わかってんのか？
ラリーウォール自体が話してるんだが

なんだこいつらキチガイか？

2025/08/31(日) 21:41:11.62

>>815
それはシェルスクリプト内で使うもの

なんでもawkでやるやつは昔から嫌われている。

いまでもawkで作り込まれていてメンテナンスがたいへんな業務システムがえるわ。

2025/08/31(日) 21:41:37.92

>>815
sed awk シェルスクリプトだな
ちゃんと書くと

2025/08/31(日) 21:43:14.03

>>817
それならC言語だろうに
スクリプト言語だとシェルスクリプト

Pythonだって外部プログラムの呼び出しばかりでPython独自のライブラリは少ない。

2025/08/31(日) 21:46:31.03

>>818
Perlの前ってことは正しいだろ

2025/08/31(日) 21:47:36.14

pythonが出てくる前の話なんだからperlだろ
perlの前はawk

2025/08/31(日) 21:59:07.78

Pythonの前だったわ

Asm->c/fortran->awk/sed/bash->perl->python->chatgpt/claude

が言語の歴史として正しいか

2025/08/31(日) 22:07:25.17

>>820
ズレまくってるな
ここまで文脈わからないのが居るのこえー

2025/08/31(日) 22:08:25.40

>>823
そう思う

2025/08/31(日) 22:14:32.43

cからawkには行かない
お手軽スクリプト言語の系譜を辿っている

2025/08/31(日) 22:56:24.41

>>823
馬鹿の代表例

2025/08/31(日) 23:05:10.32

>>823の可読性の低さがやばい

2025/08/31(日) 23:21:59.37

Pythonを置き換えるのはどんな特徴を持った言語になるのかな。それともAI利用の広がりによって、プログラミング言語というもの自体があまり使われなくなったりするのか。

2025/08/31(日) 23:50:54.85

もうテキストエディタで書くのは無理になるだろうな

概要設計や詳細設計や実装の各段階にAIが介入してきて、
オススメを提示してくる
それをそのまま使うかちょい修正して進めていくといつの間にか出来上がる

2025/09/01(月) 01:11:40.67

そもそもawkはシェルスクリプトでできないことを書くために作ったのにawkメインになるのは本来の使い方ではない。

自分がわかるものを多用するのは初心者にありがち。
bashも構文を拡張しすぎて、変なコードを書くやつがいて、こういう人間はawkも多用して、一貫性がないスクリプトを作る。

2025/09/01(月) 01:23:39.30

身の回りのことができればいいんだよ

2025/09/01(月) 06:50:05.15

ものすごい頑張ってる巨大batファイルとかよく見る

作れるのは判ったから、まともに書け

2025/09/01(月) 11:22:54.78

文法はBASICでいい

2025/09/01(月) 12:31:51.79

OPEN "TEST.DAT" FOR INPUT AS #1

2025/09/01(月) 15:52:53.01

perlは、個人的にはsedやawkのより使いやすい代用品だなぁ
単独でというより、シェルスクリプトでコマンドとして使うことが多い

2025/09/01(月) 16:15:49.04

起動時間やメモリ消費が問題になることはほぼないしな
perl/rubyで簡潔に書けることをsed/awkでコネコネしてると泣けてくる

2025/09/01(月) 16:21:42.55

60代がいるなw

2025/09/02(火) 11:36:27.12

>>809
>python出てくる前はpython的な言語ってなんだたの？
>>817
>perlの前がなんだったかって話だぞ
どっちやねん

2025/09/02(火) 14:12:33.11

>>839
関西弁アホすぎ
朝鮮人か？
バカリズム朝鮮人並みに馬鹿だな

2025/09/02(火) 18:09:20.95

なんでやねん

2025/09/02(火) 18:39:38.26

せやせや！

2025/09/02(火) 19:15:32.06

In the face of ambiguity, refuse the temptation to guess.

2025/09/02(火) 20:59:02.02

せやかて工藤

2025/09/03(水) 08:24:59.13

Pytnonは習得しやすい言語という立ち位置だし、それは実際にもそうだと思うけど、言語仕様は、全体としては結構大きくなっちゃっていて、シンプルな言語とはちょっと言いにくい感じになっているかな。
なくても何とかなるけどあると利便性が向上する機能（パッと思いつくものとしてはf-stringとかmatch文とか）が増えてくるとそういう印象になるのかも。

**デフォルトの名無しさん** (JP 0Hdf-8tKF) · 2025/09/03(水) 14:54:55.86

さてはlisperだな

2025/09/04(木) 00:57:22.22

bashの文字列操作で凝ったことすると可読性最悪になるからそこでpython使うと分かりやすすぎて感動した

**普天率土** (ﾜｯﾁｮｲ 7333-n2sn) · 2025/09/04(木) 14:39:36.17

Pythonまったく使ったことなくて
5ｃｈのスレタイ読み上げラジオをAIで作ったら3000行超えたわ
そこで初めてAIに分割して作るもんだと教わった

2025/09/10(水) 20:25:10.65

あるプログラムの出力結果の変数を構造保ったままテキストでダンプして出力しようとしてるけど難しいんだな
perlならdata::dumperで一発なんだけどな

2025/09/10(水) 20:30:53.90

コンパイルしなくて便利な分、
パット見でオブジェクトとか変数の型がわからないから、
ガッツリのプログラムは大変だね…

2025/09/10(水) 22:08:59.42

PyYAMLは？
カスタムタグでクラスも扱える

2025/09/11(木) 02:01:55.28

ありがとう
量子コンピューティングSDK:qiskitで実機の戻り調べてるんだけど
やっぱり変数の型調べながら一つずつ開いていくしかないっぽいね
バイナリの中までは調べないけどさ

っていうかperlのData::Dumperの動きの方が特例的にやばい感じで異常なんだな
まさにperlって感じ

2025/09/11(木) 04:47:38.61

pythonでcpu並列とGPU並列をまなびたいです。
おすすめのサイトありますか？

**デフォルトの名無しさん** (ｽﾌｯ Sdba-bj1o) · 2025/09/11(木) 10:07:43.70

構造調べたいだけなら
pprint.pprint(hoge)

2025/09/11(木) 18:16:56.99

>>852
Gist に Perl の Data.Dumper を Python に移植したものがあった (MIT ライセンス)
https://gist.github.com/passos/1071857

これでいけそう?

2025/09/12(金) 19:31:26.73

Pythonでサーバーサイド作ろうかと思ったけど遅いかな
ほかの言語にしたほうがいいかな

2025/09/13(土) 13:34:43.94

気になるならPyPyとかあるけど
Webアプリなら待ち時間がほとんどだから書きやすさ重視
じゃないと速度重視なAIのフロントエンドにつかわれてない

2025/09/13(土) 20:28:10.78

>>857
なるへそね
まあ速度がクリティカルじゃなければ気にしなくていいよね

2025/09/14(日) 19:55:23.96

PYTHON！
「ドッペルゲンガー（極端なそっくりさん）」を調べたら赤の他人なのにDNAが似ていた
2025.09.14 SUN
https://nazology.kusuguru.co.jp/archives/113854

ADHDの脳は実際に普通の人とは構造が異なっていた
2025.09.14 SUN
https://nazology.kusuguru.co.jp/archives/184809
>>各研究で用いられていたMRI（磁気共鳴画像）装置や画像の解析方法に“微妙な違い”があり、その影響が十分に補正できていなかったためです。この問題は以前から専門家の間でも指摘されていましたが、長年、解決が難しいまま残されていました。
>>この問題に対して、千葉大学（Chiba University）、大阪大学（Osaka University）、福井大学（University of Fukui）など国内複数の大学による共同研究チーム（代表：水野義史〈Yoshifumi Mizuno〉准教授）は、実際に複数の装置で同じ被験者を測定してそのズレを正確に補正する「TS法」と呼ばれる手法を本格的に導入し、長年の課題だった技術的ノイズを徹底的に排除しました。
>>その結果、ADHDの子どもたちの脳にどんな“違い”があるのかを、これまでになく明確に示すことに成功したという。
>>これは理屈としてはばらつきを補正する非常に優れた方法ですが、実際には大規模な協力体制と多くの技術的・資金的なサポートが必要となるため、これまで本格的に実施されることはありませんでした。
>>研究グループはこうして、ADHDの子どもとそうでない子ども、計294名（ADHDの子ども116名、定型発達（健常）児178名）の脳画像を比較しました。ここでは、年齢や性別、知能指数（IQ）などの違いも統計的にしっかり調整されています。
>>結果、ADHDの子どもたちの脳には、実際につくりの違いがあることがはっきり示されました。
◇全精神病や知的障碍者も該当しているでしょう！

まるで45億年前の太陽系!? “惑星の誕生”が初めて観測される
2025.09.13
https://wired.jp/article/exoplanet-gap-discovery/

脳から直接脳波を読み取り意思疎通　ALS患者などの生活の助けに　埋め込み型BCI装置開発　2028年の実用化に向けて年内の治験申請を目指す
9/14(日) 9:00
https://news.yahoo.co.jp/articles/cf64abfd0662436950e9bcccf85ddefd84a6b33e

2025/09/14(日) 20:14:35.23

スレチ

2025/09/14(日) 20:28:17.08

まるちんこ

2025/09/19(金) 12:09:51.27

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列を取得する方法が分かりません

よい方法を教えてください

2025/09/19(金) 12:24:49.40

>>862
1. そのレスを丸ごとコピーします
2. ChatGPTやClaude等のAIの入力欄に貼り付けます
3. メッセージを送信します
4. (ﾟдﾟ)

2025/09/19(金) 12:53:34.42

ありがとうございます！！

2025/09/19(金) 13:17:33.03

d['id1'] で 'val1' を参照できるようにしたいということなら、各行ごとに1つのdict にするんじゃなくて、全体を1つのdict にする方がいいのでは。　d = { id: val for id, val in csv.reader( file ) } とかは？

**デフォルトの名無しさん** (ｽﾌｯ Sd5f-ilUi) · 2025/09/19(金) 13:47:25.33

with open('data/data.csv', 'r') as file:
　　d = csv.DictReader(file, fieldnames=['id', 'val'])
print(d['idHOGE'])

2025/09/19(金) 16:26:18.90

今はChatGPTでも重複時はどうしますか？ってちゃんと確認してくるんだな
出てくるコードの質はともかく要点はほぼ全部網羅してくれてめちゃ親切

2025/09/19(金) 18:19:29.27

chatGPTにプログラムの質問をするときは必ずThinkingモードにすること　
デフォルト設定だとThinkingしないクソコード出してくることが多い

2025/09/19(金) 19:23:31.74

ちっとは考えろやバカタレ

2025/09/20(土) 18:48:36.37

Visual Studio Codeの変数ウォッチウィンドウが見づらいわ
他にないのかね？

2025/09/20(土) 19:05:33.94

現状VSCodeかPyCharmの二択だからPyCharmかな試すなら
やりたいことによってはJupyterが最強の場合もある

2025/09/21(日) 10:32:13.35

>>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が得られる

2025/09/21(日) 12:52:45.41

id重複時に黙って後勝ちになるが望ましいかどうか

2025/09/21(日) 13:04:55.71

そんなことはどうでもいいだろうよ
責任の所在の話したってしょうがないでしょ

2025/09/21(日) 14:22:55.90

>>871
まあ、PyCharmも似たようなもんだね…
業務レベルなので、Jupyterは無理かな…

2025/09/21(日) 14:41:37.65

awkのことはよく知らないが、連想配列でキーの重複があるの？

2025/09/21(日) 15:03:09.09

あんなのはハッシュだしな
どうやって衝突回避してるのか謎だった
今も謎

2025/09/21(日) 15:34:44.26

>>874
外部ファイルから読み込むのに重複時の振る舞いがどうでもいい場合なんてある？

仮に後勝ちは望ましくないがチェック処理を入れるくらいならサイレントにバグるので問題ないケースだとしてもそういう確認とか意思決定は明示的にしないといけないんじゃない

2025/09/21(日) 15:37:03.95

>>877
ハッシュの衝突を回避してるわけじゃなくて衝突してもいいような構造にしてるだけ
その代わり衝突が増えるにつれ性能が悪化していく

2025/09/21(日) 15:54:55.42

862を読む限り、csvファイルのキー列の値のユニーク性は前提になっていると思うんだが。だから連想配列とかdictに入れるって想定なんじゃないの？

2025/09/21(日) 15:59:04.32

>>878
データの操作とデータ構造の検査は切り分けることが出来る話でしょ
質問はデータ操作なんだからそっちにフォーカスすればいい
IDなんて名前なんだから作成元が非重複を保証してんのかもしれんし、貰い手側が質問の処理の前段でなんかチェックさせてもいい
いずれにしてもこの質問では考慮する必要のないかつ混同する必要のない事柄ってこと

2025/09/21(日) 16:40:42.51

>>878
> 外部ファイルから読み込むのに重複時の振る舞いがどうでもいい場合なんてある？

ログファイルを読み、とある項目の最新内容が欲しい場合とか。

2025/09/21(日) 17:30:15.23

>>881
俺は分けることができるとも分けたほうがいいとも思わないから考え方の違いだね
チェックを入れると内包表記を使わないほうがよくなる可能性が高かったりするわけでデータ操作と呼んでるところの内容が変わってくる

>>880
ユニークが前提となっているからどうでもよいじゃなくて「ユニークが前提なので万が一重複が来た時は後勝ちで問題ない」というところまで明確に判断しておいたほうがいいんじゃないのという話

>>882
それはどうでもいい場合じゃなくてログを読む方向に合わせて後勝ちか先勝ちかどちらか一方に仕様を決めなければいけない場合だと思う

2025/09/21(日) 17:58:13.74

何かの関数の戻り値を渡す、みたいに動作が決まってたら決め打ちでいいけど、
ファイルや通信なんか何でもありなので、
そもそも開けない、通信できない、から始まって、間違いまくったデータでもちゃんと動かないと

2025/09/21(日) 19:55:43.86

>>883
ユニーク性が前提となっていることを明確にしておくのはいいことだけど、ユニーク性を前提として設計しているにも拘らず「万一重複が来た」らそれ自体大問題だと思うけど。それは想定していた前提が成立していないということでしょ。そもそも862のようにid値を検索キーとして使う場合で「後勝ちで問題ない」場合なんてあるかな？

重複がないということを前提にできるからこそdictを使っているのであって、前提が変わってくるならデータ構造の選択とかも変わってくると思うけど。一般論としてデータに重複があっても問題がない場合かどうか気をつけようということなら素直に頷けるんだけど、862のケースで主張するのはムリがあると思うよ。

2025/09/21(日) 19:56:22.43

うましかいないよな

2025/09/21(日) 20:54:40.37

ttps://mannersy.co.jp/guivenv.htm

2025/09/21(日) 23:42:10.87

>>885
個人的にはソフトウェアの設計は想定している前提が成立していない場合の対応まで決めるものだと思ってるけど、今回のはそんな大げさな話じゃないよね

後勝ちになる実装を採用してることを自覚してそれで問題ないと判断できてるかどうか

2025/09/22(月) 00:15:54.16

重複がありうる状況なら、後勝ちで上書きしてしまう仕様で問題ないわけないだろ。862みたいに検索キーとして使っている場合に。誰がそんな状況でdictを使うんだよ、あほか。

2025/09/22(月) 00:42:13.25

>>889
上で出てきたログの例を理解できない？
後勝ちでいい例なんていくらでもあると思うんだが

2025/09/22(月) 01:23:57.89

あのさ、>>862をもう一回読んできたら？　「idが指定した値に合致するval列を取得したい」って書いてあるだろ？
idに重複があったら、val列の値の中に参照できないものが出てきてしまうわけだけど、それを許容している状況設定だと本気で思うのか？

2025/09/22(月) 01:41:53.66

>>885
「862のようにid値を検索キーとして使う場合」とか「862みたいに検索キーとして使っている場合」って書いてたら「id値を検索キーとして使う場合」のジェネラルな話をしてるのかと思うじゃん普通？

862に限定した話ならそりゃ重複時に上書きが望ましい可能性は低そうだと思うよ
だからこそ問題提起したわけで

ただ「望ましい」と「問題ない」は同じではなくて単純上書き以外の実装をする価値がないくらいに重複の可能性が低いなら望ましくなくても上書きする実装でも問題ないという判断もありえるよね
結局自覚して意思決定できてるかどうか