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/12(火) 19:52:51.31

>>723
型を明記しないとエラーとかってできる？
VBAみたいに

C++のほうが慣れてるから、そのほうがええわ

2025/08/12(火) 21:31:27.14

エラーにできるかというのが、静的型付けができていないコードの実行を自動的に抑止できるかという意味なら、Pytnon単体ではムリじゃない？　あくまでも型「注釈」に過ぎないわけだし。でも、型チェッカーの方でそういう設定はあるんじゃないかなぁ。

2025/08/12(火) 22:31:56.05

>>724
pyrightのstrict modeを試してみるといいと思う

2025/08/12(火) 22:41:38.16

Pythonの型ヒントって型推論が許されてるけどどこまでそれが効くかはチェッカーの実装依存なんだよね
つまりチェッカーからすると型が不明というのは多くの場合において自身の型推論がショボいことを意味するわけで、
不明だからエラーにするというのは筋が通らないわけよ
せいぜい引数と戻り値に方指定を必須にするくらいだね

2025/08/12(火) 23:05:23.88

実行時まで型が決まらん、というのまであるしなあ

2025/08/12(火) 23:06:06.49

商用プログラム書くならパフォーマンス犠牲になってもランタイムの型チェックがほしい
こんどしれっとtypeguardいれてみようかな
AI支援もあるし猛烈に反対はされなそう

2025/08/13(水) 06:35:34.74

>>726
まあでも、
やっぱ、オレみたいなやっぱ要望はたくさんあるんだな

型を明記して欲しいって人

2025/08/13(水) 08:37:10.53

>>730
問題は>>727の通り、どこまで明記すれば不明でなくなるのかがPythonの仕様上不明であること
例えば x = f() において、fの戻り値がstrとして型指定されている場合、右辺の式 f() の型は何になるだろう? 左辺で宣言された変数xの型はどうか?
どっちも当然strと思うかもしれないが、これ正確にはどちらも型推論が必要で、なんと型チェッカーの実装依存なんだよね
x: str = typing.cast(str, f())
もし可能な限り明記しようとすればこうなるが、これでもなお実装依存でないとは言えない

2025/08/13(水) 09:44:46.84

型付け・型検査の目的は型の不整合の有無を確認することだから、式の型が1つに確定できるならそれが最も分かりやすいとは思うけど、必ずしも1つに確定できなくても（たとえば式の型としてa型、b型、c型の3つの可能性があって、そのいずれについても）型の不整合が生じないことが確認できているのであれば、それで型付け・型検査としての役割は果たしているようにも思うけど。

2025/08/13(水) 09:48:15.23

動的型付け言語を静的型付け言語のように取り扱うのが間違い
無管理よりは何かやれることあるだろうという模索の最中だけど、本質的に困難

2025/08/13(水) 10:05:06.70

もちろん、静的型付け言語と全面的に同じことができるわけではないけれども、部分的にではあれ良いところを真似することはできるし、邪魔くさいという人は従来どおりのスタイルで書くこともできる。型指定をアノテーションにとどめるというのはそんなに悪いアイデアではないと思うけどなー。

2025/08/13(水) 12:39:57.08

PyhtonのListが型限定されたら嫌だな
もちろんPyObjectとしては限定されてるが
そういう意味じゃないんだ

2025/08/13(水) 14:26:42.51

>>727
ESLint だと明示的でない any を警告するオプションがあったりする。
型が不明という状況がその型推論がショボいことを意味したりはしないと思うがな。

ただ実用上の問題としては、型ヒントを提供していないモジュールが多いんで
警告が出まくる可能性があること。

2025/08/13(水) 16:15:18.85

自分はpylanceのbasicでちょうどいいくらいだわ

2025/08/13(水) 17:18:57.17

labelStudioのインストールについて質問してもいいですか？
WindowsパソコンでlabelStudioの最新版をインストールしたのですがコマンドプロンプトでpipコードを入力してもファイルが見つかりませんとなってlabelStudioが起動出来ません。
わかる方いますか？

2025/08/13(水) 18:47:31.75

>>738
https://labelstud.io/learn/getting-started-with-label-studio/
これでためしてみて
Dockerなんて要らないとおもうかもしれないけど
それならまずそんなところで躓かないくらいのオタクになる必要がある

2025/08/13(水) 19:30:06.31

>>739
Dockerとはなんぞや？なレベルなんてちんぷんかんぷんです。
ずぶの素人にはインストールすらむずいっす

2025/08/15(金) 00:02:17.57

pyxが出たよ

…何するツール？

https://astral.sh/pyx

2025/08/19(火) 07:51:45.77

配列でもdict使えば分かりやすいし変数名で何入るかだいたい分かるやろ
pythonて組込みには使わないし型なんているんか🐼

2025/08/19(火) 09:47:34.16

ある程度規模が大きいプログラムでないと型のありがたみは分からないと一般的に言われているのでは。個人的には一応できるだけ型は付けるようにしているけど、可読性の低下に見合うメリットを実感できているかと言われると微妙なところかな。
typingも急速に複雑化したよねー

2025/08/19(火) 11:31:08.50

型記述すると可読性が低下すると思っている人と
型記述しないと可読性が低下すると思っている人がいる

2025/08/19(火) 11:53:03.68

使わない理由は手間に見合うかどうかなんだとおもう
コードのノイズになるってんならIDEに型ヒント部分を隠す拡張があればいい

2025/08/19(火) 12:50:32.05

型ヒントを一時的に隠す機能は、たしかにちょっと欲しいかも。というか、もうあるのかもしれないけど。
他人が書いたコードとか、自分が書いたコードでも内容をだいぶ忘れてしまったコードを読むときは型ヒントが大いに助けになるけど、ある程度内容を把握しているコードだと型ヒントがない方が読みやすいってことは結構あるだろうとは思う。

2025/08/19(火) 17:20:40.65

型ヒントないとメソッドに飛べないでしょ
効率的にコーディングするために必要だよ型ヒントは

2025/08/20(水) 14:50:38.31

lambdaの本体に式しか含められないという制限は、どういう考慮からなんだっけ？　名前あり関数を定義すれば済む話なのでそこまで不便というわけではないのだけれど、lambdaの中にそのまま書けたほうが自然なのになと思うことはちょくちょくある。

2025/08/20(水) 16:32:51.46

>>748
フレームワークの概念がないのか？

2025/08/20(水) 17:15:55.62

>>748
式の中にステートメントを入れられないという大前提を覆すとなると影響が大きすぎるしそもそも思想に合わなかったからだと思う
assignment expressionの導入を嫌がってたのにも通じる話

2025/08/20(水) 19:37:21.46

JavaScriptの関数定義式のイメージで、lambdaを式ではなく文にしたらどうかという前提で考えていたんだが、仮に文にするにしても「値を持つが式文ではない特殊な文」みたいなカテゴリを作るのは大変か。そうするとやむを得ないところかね。

2025/08/20(水) 21:05:15.22

羊のラムの綴りはlamb
一旦lambを書いてからdaを付けると間違わない

2025/08/20(水) 22:25:29.24

>>737
それでもウザいかな。nodeを自分でインストールする必要ないということで、basedpyrightを使ってみたけど、デフォルトのあまりにうるささに即削除した。
uvとかruffだっけ？のチームが最近始めたやつに少し期待している。

2025/08/20(水) 22:32:03.53

AIをゴリゴリ使って基幹ソフトをRPAとPythonで便利にする仕組みを社内投稿したら、会社でバズってなんかすごいスキルとか言われて困ってる制作したことに偽りは無いけど、専門部署に呼ばれても知らんし（泣）そもそも制作のモチベーションは現場にあるから専門部署に行ってもしょうがない現場のおじさんでも作れる時代になった事がエポックメイクな事なのに

2025/08/21(木) 04:26:17.36

pyrightなんでtypescript使ってるんだろう
node系のやつ重いしなんか不具合出るから嫌い

2025/08/21(木) 04:37:15.98

pylspがいい？

2025/08/21(木) 10:33:12.22

VSCodeでPylanceを使っているけど、そこまで動作が重いとは感じないかな。警告がいっぱい出て鬱陶しいというのは分かるけど。

2025/08/21(木) 11:42:59.90

AIを使う業務ソフトならすごいけど
AIを使って作ったソフトって普通のソフトだよね

2025/08/21(木) 12:17:55.74

AIを使（って作）ったソフト

2025/08/21(木) 13:08:37.56

AIを使って作った、AIを使う業務ソフトはどうなんだ？

2025/08/21(木) 14:36:13.83

AIを使って作ったAIを使う業務ソフトを作るAIを使って作ったAIを使う業務ソフト

2025/08/21(木) 21:05:36.45

AIでなんでも作れるならフォトショップと同等のものをAIに作らせてくれや(´・ω・`)

2025/08/23(土) 09:41:55.38

言語リファレンスで、型引数リストが複合文の最後に入れられているけど、あれって文なのかな？　暫定的に置いているだけ？

2025/08/23(土) 19:28:41.00

言語リファレンス中を探し回れってか。

2025/08/23(土) 19:47:31.14

BNF

2025/08/23(土) 22:20:23.66

>>763
複合文を構成する要素だから複合文のページで説明してるだけ
式や単純文のところで説明してたらおかしい

2025/08/24(日) 01:08:14.15

それ自体としては文ではないという点に引っかかりをおぼえていたんだが、式のところに演算子についての記述があるようなものか。
ただ、type文は単純文なので、単純文の構文要素になる場合もある……が、そこはまぁ分かるでしょってことで複合文のところにあるんだろうな。

2025/08/24(日) 02:49:47.32

Pythonの内包表記やばいな
こんなんでよくperlは読みにくいとか罵れるな

2025/08/24(日) 07:50:22.46

慣れるとあれが自然言語のように読めるし、編集せずに先頭から書いていける

2025/08/24(日) 08:22:02.52

要素を表現する式やinの後が長大になることもしばしばあって、そういう場合はたしかに読みにくいんだけど、基本的にはすごい便利な構文だと思うけどなぁ。発想としては集合の内包表記っぽく書けるようにしようということなんだろうし、やっぱりHaskellは偉大だわ。

たとえばlist内包なら[ （要素を表す式） for （ループ変数・iterable変数） in （iterable） ] で、要素を表す式を書くのにループ変数・iterable変数を使うことができるというだけなので慣れればそんなに難しくないよ。キーワードのforとinが短くて埋没しやすいのが読みにくさを感じる原因なのかもしれない。

2025/08/25(月) 00:15:32.04

慣れなんかな
巨大な行列が控えてる時の

そんでもなんか人間の認知と違う気がする

2025/08/25(月) 01:44:52.02

>>771
構文の話をするやつは道具の良し悪しばかりで論じて仕事はさっぱりできない人間

2025/08/25(月) 03:06:00.70

lambdaもだけど1行に複数の要素が入るととたんに可読性落ちるんで
そこは自制するのがクールという文化(Pythonic)
lambdaはdef、内包表記は複数行にするかforで書きなおす

2025/08/25(月) 09:43:24.92

lambdaに文は入れられないが、文を含むような場合は名前あり関数として定義する方がわかりやすい……というのが一般論として常に正しいかは相当に疑問だけど。たとえば引数をそのままprintするようなごく単純なコードでも（lambdaにはできないので）名前あり関数にしなければいけないというのはかなりダルい。
Pytnonの文化は文化として尊重するし、実際、概ね妥当なアドバイスになっていることが多いとは思うけど、変えられない言語仕様を擁護するために文化を持ち出すという側面が感じられることもあるかな。

2025/08/25(月) 09:52:09.91

リスト内包が読み難いとか言ってる人は
Generatorとかどうしてるんだろうか
理解出来ないものは目に入らないタイプの人か

2025/08/25(月) 09:56:07.47

失礼、print は例として適切じゃないね。単純な代入文に読み替えて。

2025/08/25(月) 09:57:57.26

lambda x: (print(x), x)[1]

2025/08/25(月) 10:00:20.80

ジェネレーターはyieldで書けるから（強引）
ま、慣れるまで読みにくいと感じる人がいるのは分かるけどね。慣れてても「えーっと」ってなることあるし。

2025/08/25(月) 10:06:45.19

>>774
Pythonコミュニティの文化って本質的には「そんなことより仕事しろ」であって、そう理解すると色々納得できるよ
言語を変えるよりしょうもない拘りを捨てた方が早い

2025/08/25(月) 10:15:14.12

代入したければ素直に__setattr__

2025/08/25(月) 11:03:28.46

>>772
プログラムで仕事なんかしてねーし

2025/08/25(月) 11:06:33.88

>>775
ジェネレータなんて別になんもおかしくなくね？
なんか初心者には難しそうと思った要素出してきたのか？w

2025/08/25(月) 11:11:08.09

Pytnonのlambda周りの言語仕様が今さら変わるとも変えたいとも別に思ってはいないけれど、無名関数の本体には文を含められないというのは、言語仕様として中途半端で失敗だったんじゃないかなとは思っている。Pytnonはもう変わらないけれど、新たに設計される言語では（言語設計者が仮に同様に感じたなら）Pytnonの失敗を踏まえてうまく修正するんでしょ。高級言語というのはいわはシンタックスシュガーなんだからそういう点の評価・検証は大事。
ついでに言えば、Pytnonコミュニティの本質が、本当にこういう点をどうでもいいと考えているかもかなり疑問だけどね。少なくとも不満を持っている人がPytnonコミュニティの中にも少なからず居るからこそ、FAQで言い訳じみた説明をしているんじゃないかと思っているが。

式しか含められない中途半端な代物だけど、それである程度は何とかなるのでそれで間に合わせるてくれというのがPytnonコミュニティの文化だということならまぁそうかなと思う。ただ、それが本質的にどうでもいい問題で、そんなことは気にしないのがPytnonコミュニティの文化だと言われると、それは違うんじゃないのってなるかな。

>>780
素直ではないと思うけどw、lambdaでその場で書くというのを優先するならそういうことになっちゃうよね。

2025/08/25(月) 11:34:45.78

len(hoge) も糞仕様

2025/08/25(月) 12:58:40.82

最初は面食らうけど特殊メソッドで一般化できてる妙設計
糞だと思うなら代案どうぞ

**デフォルトの名無しさん** (ｽﾌｯ Sdea-ut8q) · 2025/08/25(月) 13:12:16.74

代案
hoge.__len__()

2025/08/25(月) 13:55:00.51

__len__ は今でもあるから、代案ならhoge.lenみたいにメソッド形式で呼べるようにしたいという話なのでは？　Fluent Python のどこかのコラムに書いてあったけど、よく呼ばれるのでパフォーマンスを気にしたとか何とからしいけど。

2025/08/25(月) 15:47:13.68

mapの糞さに比べたらlenなんて可愛いもんだ

2025/08/25(月) 16:01:01.59

たしかに使う機会は比較的少ないけれど、複数のiterableから並行的に要素を取得していくような場合にはジェネレーター式よりmapの方が便利じゃない？　zipだって特殊なmapなんだから、そんなに邪険に扱わなくても。

一番評判が悪いのは、文字列の連結のjoinだと思う。

2025/08/25(月) 17:18:36.19

mapレベルならジェネレータ式で書くけど
特殊な操作は明示的にmore-itertoolsつかうんで結局mapなスタイルは残るな

2025/08/25(月) 17:47:28.68

内包表記もlambdaも使うのはごく単純な処理でかつside-effect freeの場合だけ
特にlambdaは関数の引数としてインラインで書けるくらいシンプルじゃなければ基本使わない

個人的にはこれが基本原則だと思ってるけどlambdaのside-effectについて明記してるstyle guideないね

2025/08/25(月) 19:04:08.96

一般論として副作用のない式の方が望ましいのはそうだろうけど、内包表記やlambdaについて、そういう一般論を超えて副作用を避けるべき固有の事情って何かあったっけ。
自分は内包表記では（たまにlambdaでも）結構長いコードになっちゃうことがあるな。別のところに書いて名前で参照する方が分かりやすくなるならもちろんそうするんだけど、結局ここにそのまま書いた方がまだマシかなとなることが結構ある。

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
ズレまくってるな
ここまで文脈わからないのが居るのこえー