Pythonのお勉強 Part71

2023/09/20(水) 09:13:41.41

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

・当スレにRubyのソースコード類を書くことを禁ず
・Ruby等、Pythonではないプログラミング言語での回答類・質問を書くのも禁止
・「Ruby では」「Rubyでは」「Rails」正規表現→「^クソチョンw$」をNGワード登録推奨
・エラーを解決したいときは、かならず
　エラー文（勝手に省略orスクショうｐ等の横着禁止）と
　おま環（Pythonのバージョン番号＋OS名とバージョン＋IDE名）を書け。

★Pythonのソースコードを５ちゃんに直貼はインデントが崩壊するので、
　　↓等のコードうｐ用サイトに貼ってきてくだしあ。（スクリーンショットをうｐる「横着」禁止）
ttps://techiedelight.com/compiler/　　Run Code機能あり。
ttp://ideone.com/　　　　　　デフォ設定がCなので、Pythonするには言語種選択ボタン押下がﾋﾟｺ手間かも。
ttp://pastebin.com/　　　　　まずまずシンプル。
ttp://dpaste.com/　　　　　　とてもシンプル。消えるまでの日数は十分長ーく指定のこと。

◇Pythonオフィシャルサイト　http://www.python.org/
◇Pythonドキュメント　https://docs.python.org/ja/3/
◇まとめwiki　ttp://python.rdy.jp/
※前スレ
Pythonのお勉強 Part70
https://mevius.5ch.net/test/read.cgi/tech/1677856680/

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

2023/10/05(木) 10:25:53.00

>>249
3×日数を配列の長さで割れば、ある日付けにどこを読んでいるかが計算できる
なので前回読まれた時にその日の処理の中で0番目1番目2番目のどれだったのか記録しておけば直接計算できる
あるいは配列の2つ前までが前回処理された日付を読んでもいい

Pythonの問題とかじゃなくて算数の問題じゃないか？

配列の長さがNとしたら3N日ごとに全く同じパターンが繰り返されるから、最初に3N日分計算すれば永遠に同じパターンが使える
上のやり方や3で割った余りで分類する関数を書いてもいいが最初に計算するパターンのほうがミスりづらいので俺ならこっちで書きそう

2023/10/05(木) 10:35:41.65

それプログラミングじゃなくて算数の問題だからプログラミングのお題スレとかに書くと喜ばれるよ

dictのまま書くなら2つ前までの要素がいつ処理されたのかを読んで余りで処理するしかないけどめんどいから常人はやらない
辞書を継承した自作クラスにして前回どこを読んだかのカウンターを付ける
これで次回読まれるのがいつかが計算できる

2023/10/05(木) 11:58:22.11

>>244
恐らくfor～range(～)で処理しようとしているんでしょ?
while～で処理すればいいと思いますよ。

2023/10/05(木) 12:04:19.81

それか
for i in range(start_idx, start_idx+3):
　　if i>=len(list_x): i -= len(list_x)
　　～本処理～

2023/10/05(木) 12:10:07.58

do whileが無いので、代わりに無限ループにしておいて、
whileの条件が成立しなかったらbreakで抜けるというのが標準の書き方だけど、
やっぱり低級に見える

2023/10/05(木) 13:24:00.30

>>246
pythonはマイナーバージョン毎に共存できるようになってるのだから入れ直すというか新たにモジュール入れてやらないとだめ

2023/10/05(木) 18:46:58.77

>>244
学校の宿題とかパズルとかならいいんだけど
現実のシステムだと変更に弱くなるから
最後に実行された日付に不必要に依存すべきでないと思う

次はどのインデックス位置からいつ処理を実行するのかといった進捗状態を
配列とは別に保存しておいてそれをもとに計算したほうがいい
イテレータと同じイメージ

2023/10/05(木) 20:25:01.10

>>259
そうなんだありがとう
モジュールはメモしておいた方がよさそうだ

2023/10/05(木) 20:28:43.13

pip freezeでパッケージの一覧を作成できるのか
色々導入していたわ

2023/10/06(金) 10:15:56.07

なんで特定のバージョンに依存する描き方をしたがるんだろ

2023/10/06(金) 16:14:40.86

>>263
これどういうこと？

2023/10/06(金) 19:45:56.36

dockerとかrequirements.txtとか再現性高めようとすると
必然的に特定のバージョンに依存するような書き方になると思うのだが。
最新バージョンで過去のバージョンの描き方してる、とかいう元も子もない前提条件なら知らんけど

2023/10/06(金) 22:02:44.19

>>243
そのポリシーに賛同するかどうかはともかく、質問への回答にはなっていない

2023/10/06(金) 22:02:55.99

>>243
そのポリシーに賛同するかどうかはともかく、質問への回答にはなっていない

2023/10/07(土) 00:23:30.85

func( *l if a else l )
条件分岐で
*l　と　l
渡せると思ってたら
func( *(l if a else l) )
だった

親lがリストのときは*lで
親lがリスト以外のときは[l]
ってやりたいときこれでいいのかな

def func(*args):
　print( list(*args) )
l=[{"a":1},{"b":2},{"c":3}]#[["a",1],["b",2]]
#l={"d":4}
func(*(l if isinstance(l,list) else [l]) )
#[{'a': 1}, {'b': 2}, {'c': 3}]
#[{'d': 4}]

2023/10/07(土) 00:26:09.11

typeを使うのでは

2023/10/07(土) 02:03:39.77

では、とは？

2023/10/08(日) 10:38:55.23

あるいは func(*l) if isinstance(l, list) else func(l)

あるいは func(*l) if type(l) is list else func(l)

2023/10/08(日) 13:04:34.27

func if func的に２度func書くメリットがいまいちわからん

2023/10/08(日) 13:16:17.82

三項演算子だからでは

2023/10/08(日) 13:40:38.67

Pythonの三項演算子カコワルイ
C言語とかの方がパッと見て解りやすい。
(isinstance(l, list)) ? func(*l) : func(l) ;

2023/10/08(日) 13:52:37.91

コロンにそうでなければ、という意味を持たせる文化圏は無い

2023/10/08(日) 14:06:28.33

funcに返り値があったとして
f = func if func
f["res"]
# or
res = ( func if func )["res"]

またfunc内に引数分岐処理を隠蔽できる可能性を残したとして
func if func的に２度func書くメリットがいまいちわからん

2023/10/08(日) 14:47:59.95

>>274 ほんそれ
三項演算子のマクロか関数みたいなのがあったとして
tri(isinstance(l, list), func(*l), func(l))
でもまだましだったと思う

2023/10/08(日) 14:54:32.17

>>276 みたいなのがいるから
true のときの func と false のときの func が常に同じことが確実な場合
tri(isinstance(l, list), func, (*l), (l))
でも良いが

2023/10/08(日) 15:02:00.39

値を返せるifを追加してくれる方がうれしいわ
実装は関数のシンタックスシュガー

2023/10/08(日) 16:02:51.80

値を返せるifって例えばなんですか

2023/10/08(日) 16:17:18.80

むしろ値を返す方が主流だろうに

2023/10/08(日) 16:57:27.95

同じ関数を呼ぶのにアンパックするかしないかの条件分岐をさせるのは
あまり筋がよくないように感じるんだけど俺だけかな？

2023/10/08(日) 17:44:40.59

>>282
なに言ってるか解らん。
筋が良いように感じるコードを示しなよ。

2023/10/08(日) 18:05:22.35

>>279
で、できたのが今の python の三項演算子

2023/10/08(日) 18:54:48.99

>>282
普通に悪いだろうね
どういう設計かわからん
入力整形するヘルパー関数書くべき

2023/10/09(月) 00:17:46.66

式か文かのお話

2023/10/09(月) 13:00:29.46

printって
print(txt1,txt2,txt3)
って感じの仕様だけど
この仕様のメリットってなんなの？

t=[txt1,txt2,txt3]
print(*t)
みたいに書けて名前引数でもオプション設定できたりするくらい？

↑だとprintのソースコードは、def print(*values,,,option):な感じだけど
もしprintが
def print(values=[],option=,,,,**kwrgs):（valuesがlistか否かの処理）
みたいな仕様だったら実装上は
print([txt1,txt2,txt3],option)とかprint(txt1)
って書くことになる

個人的になんか見た目がダサいというか・・
単に好みの問題？

2023/10/09(月) 13:50:57.64

まあ、基本は一つだけprintだしな
スペースで区切っていくつも表示したいというデバッグ的な使い方で複数書くくらいでは

2023/10/09(月) 14:20:36.51

print "result=", value

みたいにやってた流れだろ

2023/10/09(月) 15:08:30.25

>>287
昔のPythonは()すら無かった

2023/10/09(月) 15:08:44.75

>>287
昔のPythonのprintは()すら無かった

2023/10/09(月) 17:42:01.48

>>287
実際pprintの方は引数1個しか取れなかったりする
深い意味ないんじゃない？
printは人間に見やすくするためにあるものなので今の仕様が悪いとは思わない
カッコ一つ多く書かされたらめんどい。今の仕様の理由もそんなんだろ

2023/10/09(月) 22:00:24.57

print(), print(a), print(a, b, c)と
print([]), print([a]), print([a, b, c])とどっちがいいかという話

関数定義の*argsは可変長の引数を扱う場合に
使いやすくしたり読みやすくしたりするためにある

pprintは用途的に位置引数1つで妥当

2023/10/10(火) 00:57:06.49

a = b = {}
みたいにしたらaとbは同一の辞書を指すじゃん？
aとbが別々の辞書を指すように一行で初期化できますか

2023/10/10(火) 01:14:32.36

a, b = {}, {}

2023/10/10(火) 04:09:25.99

>>295
内包表記で書けるって知りました
ありがとうございました

2023/10/10(火) 04:36:44.80

>>293
オブジェクトを人間にわかる形に翻訳して見せるのがprintの目的なんだから
位置引数1個しか取れないとしてもそれはそれで合理的ではある
逆にprintが可変長引数取れるならpprintが取れても良い
実際の使用例で便利だから引数いっぱい送れるってだけだろうな

2023/10/10(火) 23:14:31.83

Twitterで自動投稿しようと思って練習してます。
文字の投稿は成功したんだけど、画像の投稿ができません。
最近(10月)取得の無料APIでは1.1での画像アップロードはできないのでしょうか？

2023/10/10(火) 23:31:40.21

Twitterで自動投稿しようと思って練習してます。
文字の投稿は成功したんだけど、画像の投稿ができません。
最近(10月)取得の無料APIでは1.1での画像アップロードはできないのでしょうか？

2023/10/10(火) 23:46:10.35

>>297
>オブジェクトを人間にわかる形に翻訳して見せるのがprintの目的なんだから
人間にわかる形に翻訳するのは各オブジェクトに定義されている__str__の役割
どういう文字列表現にするかはprintを呼び出す前から各オブジェクトごとにすでに決まっていてprintは関知しない

逆にpprintの場合はどういう文字列表現にするかを基本的にpprintが決めている
同じ型のオブジェクトでも異なる文字列表現が要求されることを前提とした用途なので

便利な状況が多いかどうかで仕様が決まるのはその通り
つまりprintは可変長の位置引数が取れたほうが便利な状況が多いが
pprintは可変長の位置引数が取れても便利な状況があまりないということ

2023/10/11(水) 13:09:57.77

話が別の方向行ってる気がする
print、pprintであろうがなかろうが
リスト指定できるときは可変長の方がよくねって話じゃないのか

hoge([a,b,c])
ではなく
hoge(a,b,c,,,)
hoge(*args)

リスト形式とか行列扱うときは基本
それ専用のオブジェクト渡すわけだし
#objはリストを持つ
hoge(obj)

つまりかなりざっくり言うと
hoge(list)、hoge([])
はダサい、みたいな

2023/10/11(水) 18:07:12.31

>>301
>リスト指定できるときは可変長の方がよくねって話じゃないのか
リストを受け渡すところを全部可変長引数にしたら
様々な弊害が出るのはもちろんだが根本的に想定してる用途が違う

可変長引数はコレクションやコンテナにまとまった一連の要素ではなく
それぞれ独立した値を受け渡すことを主たる使い方として想定している
コレクションまるごと受け渡すのが基本的に想定してる用途なら可変長引数は使わない

2023/10/11(水) 18:19:00.12

＞様々な弊害が出る
例えば・・？

2023/10/11(水) 18:43:03.61

>>300
pprintが決めてるっていうの知らなかった。
何を使ってるの？
reprじゃなく使うものあるの？

2023/10/11(水) 18:55:29.16

文字列にするところまでは別の人で、それをどう表示するかがpprint

2023/10/11(水) 20:10:05.07

例えばRoomクラスとUserやUserクラス作ったときに
Userクラスのメソッドで[user1,user2,user3,]渡せたり
RoomクラスにUserインスタンスのリストを渡せる仕様にしたとき
まとめて渡せるけどむしろ野暮ったく感じるのはおれだけだろうか

可変長引数を使わない場合
user1=User(ユーザー１)
users = []
users.append(user1)
room = Room(users)
#room.add_user(users)
↑ユーザーを渡していますよ、というより（ユーザーだけが格納された）コレクションを渡していますよという意味合いが強まってしまう、気がする。もちろんリストを渡さなければいいわけだがそれだとadd_usersなど複数形のときにはリスト渡そうね、といったアノテーションが増える。なんか野暮い

可変長引数を使う場合
user1=User(ユーザー１)
room = Room()
room.add_user(user1)
#room.add_user(user2,user3,,)
#users=[user4]#users.append(user5)
#room.add_user(*users)
↑ユーザー単体を渡している感が強まる、気がする。add_userで可変長引数使いたくないときはそもそもひとつしか渡さなければいいし、複数可は可変長引数をもったadd_usersにでも任せればいい（なければ使えないだけ）。渡された値の正否に集中できるので例外処理がシンプル

リスト渡したいときは、リストの各値の扱いがバラバラのとき、[int,str,obj1,obj2,,,]みたいなときくらいしか無いような気がするんだがそれだと、そもそも設計ミスのような。もちろん近くのコンビニに部屋着で行く感覚ならどうでもいいと思うけど

2023/10/11(水) 21:05:21.93

そもそも可変長で追加したいと思ったことないや
1個追加するappendでforループ回したほうがバグりづらくない？

どうしても用意したいならappend, extend,で list の操作と名前を揃えるとか？

2023/10/11(水) 21:11:21.59

Pythonって配列の形状の指定がないことが多いから、長さ不明なスターアンパック自体やっぱ危険じゃね？と思う
それで書くのが明らかに簡潔なケースでは当然使うけど、そういうのも最終的にはリストかnumpy配列の委譲で実装しちゃうからメソッドの名付けで困ったことはないかも
委譲先のをパクる

2023/10/11(水) 21:48:59.91

スターアンパックで危険って例えば・・？

2023/10/11(水) 22:06:40.32

numpyとかはコレクション自体が本体みたいなもんだからリスト渡すのはわかる
しかしリストの各値を個別で扱いたい場合、各値を扱う目的とは別に
その値を格納したリストそのものに別の目的が生まれてしまう
その次元を下げてくれるのがスターの目的だと思う

2023/10/11(水) 22:14:51.53

＞そもそも可変長で追加したいと思ったことない
それは普通にそれでいいんじゃね

可変長使わずにadd_users追加しましたってときに
「usersなんだから”当然”リスト渡すよねー（渡すのはリスト型だよねー）」（もっと言えばuserのみが格納されたリスト型だよねー、またはusersオブジェクトとかでもいい）
みたいなアノテーションが必然的に発生するのがモヤモヤするだけで。

2023/10/11(水) 22:51:38.36

>>306
そのケースは基本的に可変長引数を使う状況ではない
1件追加するためのAPIと複数一括で追加するためのAPIは分けるべき

複数一括で追加するメソッドの中身が1件1件追加するのと同じ処理なら
後者のAPIは用意せず利用者側がループを回すのでも十分

一括処理の最適化がされてるなら複数形にするだけでなく
複数件一括処理であることを示す命名を状況に合わせて考えればいいと思う

2023/10/11(水) 22:56:16.70

＞そのケースは
どのケースのことを言ってるのかまったくわからんが
使わないなら使わなくていいって言ってるがな

2023/10/11(水) 22:58:21.14

>>304
各オブジェクトのreprを利用する場合もあればしない場合もある
そういうのを含めてどういう文字列表現にするかをpprintが決めてるということ

pprint自体はpythonで書かれててそんなに難しくないからソース見てみればいいよ
https://github.com/python/cpython/blob/3.12/Lib/pprint.py

2023/10/12(木) 10:46:44.12

>>301
呼ぶ側でパラメータが複数のときと1個であることが判ってるときに
fuga = [a, b, c]
hoge(*fuga)
と
hage = [p]
hoge(*hage)
の様に無理やりくっつけるのはダサくないのか？
hoge(p)
で良いだろ？

2023/10/12(木) 11:11:35.88

不合理なこと、手間がかかること、読みにくいことを避ける
合理的で簡潔で読みやすければ、ダサくてもそれが正解

2023/10/12(木) 11:47:55.21

みんなが何の話をしてるのかわからん
ある特定のケースで関数が引数に可変長引数かリストのどっちを受け取るべきかっていう話？
それとも、そもそも可変引数は引数は必要かっていう話？
今の議論に** オペレータは含まれる？

2023/10/12(木) 11:49:19.75

>>317
>それとも、そもそも可変引数は引数は必要かっていう話？
それとも、そもそも可変引数は必要かっていう話？
ちょっとみすった

2023/10/12(木) 11:49:27.64

>>317
>それとも、そもそも可変引数は引数は必要かっていう話？
それとも、そもそも可変引数は必要かっていう話？
ちょっとみすった

2023/10/12(木) 13:25:38.85

PythonでStableDiffusionで使われるsafetensorsをonnxファイルに変換するアプリを作り、ユーザーに配布したいのですが、ユーザーにPython環境を構築させないで済む方法があれば教えてください
GUIから使用したいのでPythonでコマンドラインアプリを作成しC#で作ったGUIからC#のProsses.Start()で起動して動かしたいと思いますが
例えばPythonをインストールしていないPCでProsses.Start("〇〇.py")をやっても動きませんよね？
どうすればいいでしょうか？

2023/10/12(木) 13:35:59.07

>>315
＞複数のときと1個であることが判ってるとき
うん、だからadd_itemで可変長使いたくないなら使わなくていいしadd_itemsで可変長使えばいいし
別に可変長使ったadd_itemでitem複数追加できる仕様にしてもいいしって言ってる
add_itemであろうがadd_itemsであろうが
リスト渡す場合に「当然リスト形式で渡すよね」というアノテーション発生が問題なのであって、と言っている
リストに限らず、リスト渡すなら渡すで、オブジェクト渡すなら渡すで、
どうしてその形式なの？の前提があるでしょ

2023/10/12(木) 13:41:54.06

>>303,309
が知りたい

2023/10/12(木) 14:32:29.65

あえて複数形のない日本語で考えるとわかりやすいかもな
add_うどん()
add_うどん(うどん)
うどんが何うどんだとかどこ産のうどんだとかは、add_うどんメソッドには依存しない
とにかく、うどんを渡せばよくて
そのうどんが、うどんクラスのインスタンスだったりするかもしれないってだけ
だが、リストで渡せてしてしまうと
add_うどん([うどん、うどん、うどん、、])
[]←これなに？　→　うどん（など）の配膳カートです
これはうどんじゃなくてカートを渡したってことになる

「カートには入れたが、複数杯（や玉）のうどんを渡したって意味な」
というのが自分も含め通じてしまうのは
Listはそうときに使う（使いたい）からっていう共通認識だけでしかない

"add_うどん_を_配膳カート_で_()"
とかだったら配膳カートをクラス化して渡せばいいし
（リストの機能で十分なら）クラス化せずともリストで渡してもいいのはわかる
でも大抵、リストを渡す時はそこらへん省略されてるかアノテーションで判断してる気がする
なぜならadd_うどん内部での配膳カートはイテラブル程度の機能しか使わないことが多いから

リストを渡す、は本当はそれ自体に意図があり
可変長引数はその意図を論理的に省略することができる

2023/10/12(木) 15:36:59.50

なんか知らんが草

2023/10/12(木) 15:40:56.90

>>309
危険というか単にバグりやすくなるってだけ
多重配列が危ない
リストのリスト、リストのリストのリストとかでアンパック使うと少なくとも俺はすぐバグる
あんまり入れ子になるなら普通は自作クラス定義するがリストとタプルで済ませたいこともあるから

自作データクラスのリストとかは多重配列に近いと思うのでアンパックをホイホイ使うとバグりやすいんじゃないかなと

2023/10/12(木) 15:47:06.45

アンパック使ってもforで書いてもほとんど同じだけど多重配列ならforの入れ子で書いたほうが階層の把握に間違いがないってことね
１重配列なことが確実ならスターアンパックで問題ないと思う

2023/10/12(木) 16:07:06.78

組み込みの型を使ったらそうなるって
listにはlistという意味しか無いんだから
型に意味を持たせたいならクラスを作るしか

2023/10/12(木) 16:22:18.67

＞バグりやすくなる　＞少なくとも俺はすぐバグる

なにこれ
めっちゃふわふわしてて全然わからん
具体的にどういうとき・・？

2023/10/12(木) 16:27:05.61

>>327
＞型に意味を持たせたいならクラスを作るしか
そうだよだからクラス作って渡せばいい
でも結局、そのクラスがリスト持つなら同じように
そのクラスのリストに>>323のような意図が出てくるだけ

**328** (ﾜｯﾁｮｲ 0d01-5AJl) · 2023/10/12(木) 16:39:38.79

一応自分でも考えてみたが多次元配列をスターで再帰するときとか？

def recursive_array_print(*args):
　　for item in args:
　　　　if isinstance(item, list):
　　　　　　recursive_array_print(*item)
　　　　else:
　　　　　　print(item)
nested_array = [1, [2, [3, 4], 5], 6, [7, 8]]
recursive_array_print(nested_array)

例えばこれは数値だけだからまだいいけど
辞書やらだった場合に条件分岐が面倒とか・・？
でもそれバグというより設計ミスだしな
バグってなんだろ

2023/10/12(木) 18:00:33.28

個人的に第一引数設計の優先順位は
①単数
②単数・複数（可変長引数）＝　③単数・複数（関数名に引数の意図を明示＆リスト）
④単数・複数（単純展開が目的のリスト）

①はよく見る（というか複数しなければほぼ必須なので当たり前）
②は①で実装できる範囲なのであまり見ない（例 [ list.append(i) for ]）
③をするくらいなら渡す値をクラス化していることが多い
④は①で実装できる範囲なのであまり見ない、個人用途コードでよく見る

第一引数でなくとも（行列の演算でもない限り）リストを渡すのは微妙

**317** (ﾜｯﾁｮｲ e943-nnu1) · 2023/10/13(金) 10:32:08.61

誰か教えて下さい、、

2023/10/13(金) 10:36:29.66

>>331
>②単数・複数（可変長引数）
可変長引数は単数・複数を同時にサポートするためにあるんじゃないんだよ
そもそもの大前提として一つの関数や一つの変数で単数・複数を同時にサポートしようとするのは特殊なケースを除いて基本的に悪手だからね

2023/10/13(金) 10:40:10.61

＞同時にサポートするためにあるんじゃない
printさん・・

2023/10/13(金) 10:44:37.94

ん・・ちょっとまてよだったら可変長引数使う時は
hoge()　←ダメ
hoge(a)　←ダメ
↑は条件分岐でそもそも実行させないようにして
少なくとも
hoge(a,b)
ここから推奨ってこと？
可変長ってそんな概念だったっけ・・？

2023/10/13(金) 10:48:38.24

>>333
＞同時にサポートするためにあるんじゃない
ドキュメントやらどこかに明記されてたってこと？

2023/10/13(金) 11:33:13.84

pythonの設計思想は知らんけど
＞かへん‐ちょう〔‐チヤウ〕【可変長】長さ・桁数・文字数・データの大きさなどが定まっていないこと。
言葉の意味からして
＞同時にサポートするためにあるんじゃない
はさすがに違和感あるわ

2023/10/13(金) 11:46:57.67

> 長さ・桁数・文字数・データの大きさ
のどれでもなく、パラメータの個数だよな

2023/10/13(金) 12:01:59.94

などが

2023/10/13(金) 12:21:03.84

lengthが数を表すという文化が歪んでるんだよな
なんでlenじゃなくてsizeにしなかったんだろう

2023/10/13(金) 13:11:04.18

自分の誤読をごまかすために文化に難癖つけ始めた

2023/10/13(金) 14:03:08.40

おはよう！
https://ideone.com/6RegCA
これがエラーがでるんだが。
どうしたらいいのでしょうか？

2023/10/13(金) 15:48:46.04

単数・複数の定義からはじめないといけないのか

先の例を借りるなら
def add_user(user: User)が単数
def add_users(users: list[User])が複数
この2つを一つの関数でサポートしようとして
def add_user(*users: User)のようにするのが間違った可変長引数の使い方

2023/10/13(金) 16:27:41.27

>>343
＞間違った可変長引数の使い方
エラーでるの？
バグりやすいの？
>>336 ＞ドキュメントやらどこかに明記されてたってこと？

てか同じこと言ってない？ｗ
で、言う割にはなぜか論理的に説明はできないっていうの繰り返してるような

2023/10/13(金) 16:50:17.50

根拠がダサいだしな
ダサいかどうかを基準とする考え方はダサい

2023/10/13(金) 17:31:26.11

すべて羅列するなら（名前付き引数や**kwargsは除外）
単数
①def add_user(user: User)　#一般的
②def add_user(user: List[User])　#関数名からListである必要性を連想できない
③def add_user(*user: User)　#あるっちゃある例print
④def add_user(*user: List[User])　#②同様
複数
①def add_users(user: Users)　#UsersのUser取り出しロジックがUsersのデータ型に依存、関数名での補足がいると思う
②def add_users(user: List[User])　#よくみる、①の発展、だがList展開ロジックが必須で暗黙的
③def add_users(*user: User)　#＝単数③、より明示的
④def add_users(*user: List[User])　#＝単数④

単数④複数④は無い、関数名次第ではアリ

あくまでadd_user,add_users名でやるなら
単数①、単数③、複数③、複数②だな
本質は複数①②が同列に扱われている、という部分だと思う

2023/10/13(金) 18:25:27.74

最近Python始めたんだがGitHubで公開されてるStableDiffusionのsafetensorsファイルをOnnxファイルに変換するスクリプトをクローンして使って見たんだ
その中でハギングフェイスのライブラリ使ってんだがそのライブラリに変更があったみたいでスクリプトがまともに動かなくなってた
Pythonってこういうことよくあるの？

2023/10/13(金) 18:29:10.51

>>344
ごめん、そもそもadd_users(*users)と書く設計にしても全然動くわけで
どう書くと「書く側の人間が」「バグらせやすい」という話を一貫してしてると思ってたのでまさかそこが理解できないとは思わなかった
「バグりやすい」より「バグらせやすい」と書いたほうが親切だったね、どちらでも意味が通るけど

2023/10/13(金) 18:36:26.11

>>330
来る配列の深さもshapeもわからないなら再帰で書くしかないからそれはスターアンパックで書いて構わないと思うよ

２重配列とか３重配列とか、numpyで言えばndimとかshapeの一部が決まってる多重配列を扱う場合にスターアンパック使うのはよくないと思う
こういうのは俺が勝手に言ってるだけでもなくて例えばEffective Pythonには4つ以上の要素を含む(1次元)配列をスターアンパックするなと書いてある
２重、３重、４重とかの組み込み型の多重配列は普通にコード書いて出てくるがそれらをほいほいスターアンパックすればよりバグを生みやすいと思う
add_users(*users)は俺にはアンチパターンに見える

2023/10/13(金) 19:36:16.66

＞add_users(*users)は俺には
嫌ならそう書かなければいいだけでは・・？
多重配列の生成とその扱いを混同してるんだと思うが
usersがUserクラスを持つならそれに従えばいいと思うぞ
例えば４つ以上といわず[np,np,np,,,,,]扱う、みたいなケースがあるのかはしらんが
無理にスターアンパックする必要ないわけで
>>308＞書くのが明らかに簡潔なケースでは当然使うけど
と同じように逆然りでしょ

2023/10/13(金) 19:38:42.67

print関数という実績

2023/10/13(金) 19:57:29.33

add_users(user1,user2)と書いてもadd_users(*users)と書いても動いちゃう
だから（書く側の人間が）バグらせやすいんだ
そんなことある・・？
False==0で動いちゃった、よりよっぽどましだと思うが。。
だって少なくともエディタの補助範囲内だし

2023/10/13(金) 20:09:45.61

自分の取り扱ってるデータが何なのか理解せずに関数に渡すことがまずありえないしな