Pythonのお勉強 Part74

2024/09/21(土) 10:14:02.15

!extend:default:vvvvv:1000:1024
!extend:default:vvvvv:1000:1024
↑スレ立てる毎に減るので、減ってたら３つに補充すること。

※前スレ
Pythonのお勉強 Part73
https://mevius.5ch.net/test/read.cgi/tech/1717631290/

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

2025/02/16(日) 12:09:07.95

(a, b): (int, int) = (0, 0)

2025/02/16(日) 13:10:26.00

>>660
a, b = 1, 2とすればaとbが個別のローカル変数としてスタックフレームに追加されるだけ
CPythonでは定義順になるから内部の配列内で隣接してる場合もあればしてない場合もある
スタック上の変数でかつそれぞれ直接アクセスしかしないんだから隣接してるかどうかは実用上はどうでもいいこと

2025/02/16(日) 13:51:57.18

そうでしょ、やっぱりメモリレイアウトが全然違うよね。
一括代入の左辺の場合には、その後もタプルとして使われることは全くなく個別的にしかアクセスしないのだから、メモリ上隣接しているかどうかがどうでもいいというのはある意味当然のことで、それは、通常の意味でのタプル（固定長でimmutableなコレクション・コンテナとしてのタプル）でないことの裏返しだと思うけど。
言語仕様上はそれもまたタプルとして定義されているということであれば「タプルではない」というのは正しくないことになるしそれはそれで構わないのだけれど、重要なのは通常の意味でのタプルとは全く別物だという点であって、その点の認識はあった方が良いんじゃないかなぁ。

2025/02/16(日) 13:58:47.89

a, b = 0, 0
構文解析上の文法は
(a, b) = (0, 0) の略
ではなく
a, b = (0, 0) の略
じゃないかな
代入前(右辺)はタプルで代入後(左辺)はタプルではなく個別
もし左辺がタプルならbindされた名前が無いので利用出来ない

2025/02/16(日) 14:30:13.56

一括代入の左辺のターゲット並びは、丸括弧や角括弧で囲うことも全く囲わないこともできる。
角括弧で囲った場合はリストになり、丸括弧で囲った場合や全く囲わない場合はタプルになるということはできるけれども、通常の意味でのリストやタプルとはまったく別物だし、その後もリストやタプルとして利用されることはないので、それがリストやタプルであるということにどれほどの意味があるのか、むしろ通常の意味でのリストやタプルと混同してしまう人が出かねない弊害の方が多いのではないかというのが個人的な感想。
むろん、言語仕様上、リストやタプルとして定義されていますということであれば、あえて逆らうつもりはないけれども、リストやタプルの概念の中に異質なものを抱え込むことになって概念内容が拡散するように思うし（e.g.要素に代入できるタプル）、概念整理としては、一括代入の左辺については、リストやタプルのリテラル構文の形式を借用した代入構文の一形式であって、それ自体としてはリストでもタプルでもないという形で整理した方が遥かに分かりやすいのではないかと思っている。

2025/02/16(日) 15:20:14.54

>全く囲わない場合はタプルになるということはできるけれども

いや出来ないやろ

2025/02/16(日) 16:31:54.22

自分は、一括代入の左辺については（通常の意味での）リストやタプルとは区別した方がわかりやすいのではないかという立場だけど、これらもリストやタプルであると考える立場に立つ場合、その中で、丸括弧で囲むか否かによってタプルになったりならなかったりするという考え方はないんじゃない？　ASTでは丸括弧がなくてもタプル扱いみたいだし（>>658）

2025/02/16(日) 16:50:55.15

左辺がタプルになる代入は
c = 0, 0
とか
_ = 0, 0
の場合な訳で
(後者は暗黙で名前が付かないbindの例で敢えて描いたけど)
(a, b) = 0, 0
はタプルに代入してる訳じゃないでしょ
という立場ですね

2025/02/16(日) 17:02:45.20

>>669
>>647
タプルでもリストでもない何かとしてもいいけどね
即値だけのコードも正当なのでbinding(assignment?)の有無は根拠にならんかも

2025/02/16(日) 17:36:27.88

c = 0, 0 と　_ = 0, 0 は、代入ターゲットが1つしかない単一代入の文だから、今の話題と直接的な関係はないかと。

一括代入として、
ア　 a, b = 0, 0
イ　(a, b) = 0, 0
ウ　[a, b] = 0, 0 の3つの文に実質的な違いは（おそらく）何もなく、あえて左辺がタプルだリストだという必要はないのではないか（少なくとも通常の意味でのタプルやリストではないので、これらがタプルやリストであると考える意味もほとんどないのではないか）、それよりも一括代入の構文として共通のものとして理解する視点の方が有用なのではないかという感覚かな。
言語仕様上、リストやタプルの概念がこれらも含むような形で定義されているかはまた別の問題として。

2025/02/16(日) 22:36:18.21

個人的には一括代入って言葉の方がよっぽど気になるけどな

2025/02/16(日) 22:53:37.86

用語法はまったく本質的な部分ではないので、意味が通じれば何でもいいと思うけど。一括代入、複数代入、多重代入、併行代入……好きなのを使えばいいんじゃない？　既に定着している用語法があるならそれに従っておく方が無難だとは思うが。
あとa = b = c みたいなのと語感上、区別しやすい用語だとなお良いね。

2025/02/16(日) 23:06:15.10

じゃ左辺のタプルも意味が通じればなんでもいいんじゃない？

2025/02/17(月) 00:13:36.55

要素に代入できるタプルというものを観念して、いわば特殊なタプルと位置付けてタプル概念に含める方向性で考えるのか、タプルとは区別して整理する方向性を指向するのかというのは、理屈としてはタプル概念の外縁の画定に関する1つの態度決定の問題だから、重要でないとはいえないだろうし、タプルに含める立場をとる場合でも、通常の意味でのタプル（immutableな固定長コンテナとしてのタプル）とは質的に異なるということを意識しておくことは実践的にも意味がある……と自分なんかは思うけど、人の考え方はさまざまだからね。674が、用語法の違いと同程度のどうでもいい問題だと思うのなら、実際674にとってはそうなんでしょ。そのことを否定はしないよ。

2025/02/17(月) 00:31:13.10

利用者から観察できんし内部処理知ってると最適化できる類のもんでもなさそう
今の処理系でどういう扱いしてるのか知りたいならわかるけど
個人的にはどうでもいい寄りというかあえて意識したくない話かな

2025/02/17(月) 11:24:47.42

「正確にはタプルじゃない！」とイキった手前どんなに見苦しい言い訳を繰り返してでも自己正当化したいのだろう

2025/02/17(月) 12:14:13.77

タプルオブジェクトではないとでも言っておけば不毛なレスバしなくてよかったのにね

2025/02/17(月) 12:36:50.89

レスバしたという感覚はないし、そんなに間違ったことを書いたつもりもないんだけどな。678のいう「タプルオブジェクトではない」という表現の方が受け入れやすいということなら別にそれで構わないと思うし。

2025/02/17(月) 16:30:08.05

5chで細かいところまで正確に伝えるのは難しいんだし
あんまり気にしなくていいんじゃね
SNSは議論に向かないしさ

2025/02/18(火) 01:50:34.73

辞書に追加する方法を教えてほしいです
存在しないキーを追加してその中にさらにキーを追加したいです
以下だとエラーになりました

https://pastebin.com/k1VaU5GZ

2025/02/18(火) 02:55:12.14

>>681
d["tomorrow"] = {"トマト": 70}
ではどうだろう。(未検証)

2025/02/18(火) 03:32:54.30

>>682
うまくいきました！
どうもありがとうございます！

2025/02/18(火) 03:48:38.37

>>681
この関連ですけど、辞書の中の辞書の一部のキーのバリューを変更するにはどうしたらいいですか？

todayのりんごの値はそのままでみかんだけ40にしたいです

2025/02/18(火) 08:18:06.27

>>684
値の変更はこれで良いのでは。

> d["tomorrow"]["トマト"] = 70 # これだとエラーになる

2025/02/18(火) 08:51:43.27

混乱させるかもしれんけど標準モジュールcollectionsにあるdefaultdict使えば
from collections import defaultdict
d = defaultdict(dict, {"today": {"りんご": 100, "みかん": 50}})
d["tomorrow"]["トマト"] = 70
でエラーにならない
d["tomorrow"] の時点で {} が自動生成される

2025/02/18(火) 09:17:41.68

get, setdefault, collections.defaultdict, __missing__ の違いについては、たしかEffectivePythonで2〜3項目さかれていたね。

2025/02/18(火) 11:02:20.10

まあうまくいくだろうし便利だろうけど
キーのスペル間違いとかがチェックされない怖さはあるな

2025/02/19(水) 07:26:57.60

亀レスすみません
みなさんありがとうございます

>>685
これでうまくいきました

>>686
エラーにならず.getのように自動生成されるのはいいですね

2025/02/19(水) 07:46:07.12

いきなり参照してエラーになるのは嫌なので、
いつもgetを使うようにしよう

というのは必ずしもいい考えじゃないんだよな
エラーにならない筈のものがエラーになるなら異常なので捕まえるべき
本気で何が入ってるか予想できないケースではgetを使うしかないけど、
そんな状況になるのも何か間違ってる

2025/02/19(水) 08:27:04.14

noneが帰るならそれキャッチしとけば同じじゃない？

2025/02/19(水) 09:44:18.83

新しいキーが挿入されるのはsetdefaultやcollections.defaultdictであって、getは別に新しいキーは挿入されないんじゃなかったっけ？

2025/02/19(水) 16:01:59.58

想定していないことは例外にする
局所的に意図してフォールバックさせたいときはget
恒常的にはdefaultってだけよ

2025/02/19(水) 20:05:14.43

継承したクラスにあった__repr__()をそのまま使って欲しいのにうまく行かない

2025/02/19(水) 21:58:33.63

keyerrorとかindexerrorとか事前にかわせるやつも例外にするのどうなの？
なんかコスト高そうな印象だけど

2025/02/19(水) 22:19:23.68

VMといえど高いし気になるならin (__contains__)を使えばとしか
オレはコードの意図がつかみやすいかで使い分けてる

2025/02/19(水) 22:48:10.15

Rustとか最近の言語って例外ないらしいじゃない。そっちの方が優れているというのがコンセンサスになったらPython4とか5とかのメジャーパージョンアップのときにそちらに舵を切るということもありうるのかな？　自分は3以降でPythonを知ったので、2→3のときの大改革ってのは未経験なんだけど。

2025/02/19(水) 22:56:14.91

3での変更点って、ええー2ではまだそんなこと考えてたのという、
3が先進的というよりは2が後進的で、
pythonなら当然そうするでしょという感じなんだよな

2の頃はまだperlをメインに使ってた

2025/02/19(水) 22:59:08.90

2はprintがステートメントで
ステートメント？！と驚いた
と思ったら3でもdelがステートメントでまた驚いた

2025/02/20(木) 00:52:57.36

パイチョンはインタプリタが全然頑張らないアホの子

2025/02/20(木) 04:49:24.69

毎日が新鮮な驚きに溢れて楽しそうですね

2025/02/20(木) 11:00:03.67

>>697
Pythonは、ぼくこんぴゅーたのむずかしいことわかんないけどえーあいあぷりつくるんだもん！な子を満足させる使命があるから例外は必要
彼らが例外を放置してもアプリが止まってしまわないのはフレームワークが最終的にケツを拭いてくれているおかげ

**デフォルトの名無しさん** (JP 0Hcb-ek9F) · 2025/02/20(木) 19:27:27.78

例外処理って必要？
書かなくてもPython自身が例外を出して止まるよね

2025/02/20(木) 19:58:06.02

変な値が入力されたらエラーを表示したい
でも入力部分はずっと下の階層の処理なので、
エラーの情報を上までバトンリレーしないといけない
例外なら言語がやってくれる

2025/02/21(金) 06:33:27.06

ギャンブルのデータ分析？とai予想したいのですが、どういう環境がいいんでしょうか？
anacondaが定番のような気がしますが、ローカルだとマシンパワーがどうなのかなと。

unityみたいなゲームエンジン上でも出来たりしますか？

2025/02/21(金) 10:53:50.45

GoogleのColabでええよ

2025/02/21(金) 11:17:38.16

>>703
例外処理っていうのは例外が発生した場合にリカバリー可能な処理を書くんだぞ
その辺わかってなくて単純に例外の時にって思ってる奴が多い

具体例で言うと通信
ゲームとかのアップデート想像してみればいい
大容量データダウンロードしてる時に通信状況が悪くなった
例外処理が無ければそのまま例外吐いて失敗となる

ここで例外処理として通信状況が良い所に移動しろ的なメッセージを出して続行ボタン押させたり、数秒から数十秒間隔で通信を再開させるようにした場合は処理がスムーズになるやろ

こういう風にリカバリー可能な処理を書くのが例外処理やで

2025/02/21(金) 11:41:35.66

>>705
もちろんUnityでも出来るよ

2025/02/21(金) 13:53:02.83

>>708
一般的にデータ分析ってアナコンダとか使うんですかね？
ゲーム目的じゃないですから

2025/02/21(金) 15:26:48.94

現実世界の様子やUIを理解してタスクをこなせるマルチモーダルAIエージェントの基盤モデル「Magma」をMicrosoftが発表
https://gigazine.net/news/20250221-microsoft-magma/

悪用されている

2025/02/21(金) 17:14:00.29

>>709
anacondaというよりjupyterを使う
なのでgoogle colabでも良いしvscodeのプラグイン入れてでも良い

2025/02/21(金) 18:41:20.24

>>711
ありがとう
jupyterlってのが必要なんすね
機械学習をunityでやろうとしてましたけど、それと別途で用意します

2025/02/21(金) 18:53:52.10

>>712
>>711みたいな馬鹿を信じるなよ

2025/02/21(金) 19:06:12.50

LLM の推論機能を活用する新しいバックドア攻撃「DarkMind」が提唱される
https://gigazine.net/news/20250221-darkmind-chain-of-thought/

AIはチェスで負けそうになるとチートする
https://gigazine.net/news/20250221-ai-chess-cheating/

2025/02/21(金) 23:21:50.44

from datetime import datetime

t_start: str = "23:00"
t_end: str = "24:00"
t_start_dt: datetime.datetime = datetime.strptime(t_start, "%H:%M")
t_end_dt: datetime.datetime = datetime.strptime(t_end, "%H:%M")
unix_t_start: float = t_start_dt.timestamp()
unix_t_end: float = t_end_dt.timestamp()

x = int(unix_t_end - unix_t_start)

print(x)

t_endが24だと以下のエラーが出ます
24時間表記の時は%Hではないんでしょうか？

ValueError: time data '24:00' does not match format '%H:%M'

2025/02/22(土) 00:07:13.49

>>715
知らんけど時間って
00:00:00～23:59:59
ちゃうの？

2025/02/22(土) 00:28:58.03

不親切なエラーだよね

2025/02/22(土) 00:58:09.16

境界値の問題って定番じゃね
テストケースにも必ずいれるだろ

2025/02/22(土) 07:44:50.26

閏秒なんか廃止で当然だよな

2025/02/22(土) 12:10:03.03

>>716
ありがとうございます
このようにしてみましたがもっとスマートな方法ってありますか？

from datetime import datetime

t_start: str = "23:00"
t_end: str = "24:00"
if t_end[0:2] == "24":
t_end = f"00:{t_end[3:5]}"
t_start_dt: datetime.datetime = datetime.strptime(t_start, "%H:%M")
t_end_dt: datetime.datetime = datetime.strptime(t_end, "%H:%M")
unix_t_start: float = t_start_dt.timestamp()
unix_t_end: float = t_end_dt.timestamp()
if t_end[0:2] == "00":
unix_t_end += 86400 # 24時間足す
x = int(unix_t_end - unix_t_start)
print(x)

2025/02/22(土) 12:19:18.21

何がしたいのか不明だけど、時間の計算にはtimedeltaを使う

2025/02/22(土) 12:35:47.16

>>721
ありがとうございます
調べてみます

2025/02/22(土) 12:42:40.44

やりたいことはt_startとt_endの中に入ってる文字列の時刻の差分を求めたいです

2025/02/22(土) 12:44:39.38

といいつつ、日付ではなく時間の長さをhh:mm:ss形式で書きたい時用に、
秒単位のfloatと文字列の相互変換ライブラリを自作した
標準にはいいの無い

2025/02/22(土) 12:51:12.03

うちのライブラリで書くと、
delta = str_sec(t_end)-str_sec(t_start)
print(sec_str(delta))
こんな感じになる

2025/02/22(土) 13:11:12.71

途中経過ですけど今こんな状態です

t_start: str = "23:00"
t_end: str = "24:00"

dt_now = datetime.now()
t_start_dt = datetime(year=dt_now.year, month=dt_now.month, day=dt_now.day, hour=int(t_start[0:2]), minute=int(t_start[3:5]))
if t_end[0:2] == "24":
dt_d = dt_now.day + 1 # もし現在が月の最終日だとエラーになる "ValueError: day is out of range for month"
t_end_dt = datetime(year=dt_now.year, month=dt_now.month, day=dt_d, hour=0, minute=int(t_end[3:5]))
else:
t_end_dt = datetime(year=dt_now.year, month=dt_now.month, day=dt_now.day, hour=int(t_end[0:2]), minute=int(t_end[3:5]))
x = t_end_dt - t_start_dt
print(t_start_dt)
print(t_end_dt)
print(x)

2025/02/22(土) 13:58:51.98

何度もすみません
とりあえずこうなりました
なんだが余計に長くなった気がします

from datetime import datetime

def strToDt(str_dt: str):
dt_now = datetime.now()
# TODO 25や26の場合があるかもしれないので24決め打ちはやめる
if str_dt[0:2] == "24":
next_dt = dt_now + timedelta(days=1)
dt_dt = datetime(year=next_dt.year, month=next_dt.month, day=next_dt.day, hour=0, minute=int(str_dt[3:5]))
else:
dt_dt = datetime(year=dt_now.year, month=dt_now.month, day=dt_now.day, hour=int(str_dt[0:2]), minute=int(str_dt[3:5]))
return dt_dt

t_start: str = "23:00"
t_end: str = "24:00"

t_start_dt = strToDt(t_start)
t_end_dt = strToDt(t_end)

x = t_end_dt - t_start_dt
print(t_start_dt)
print(t_end_dt)
print(x) # 時間:分:秒形式
# TODO xを分形式に変換する

2025/02/22(土) 14:01:58.99

初学者だと思うけど
end>startが保証されてるなら
>725
みたいに秒に変換して引き算が正解じゃない？

2025/02/22(土) 14:16:15.84

>>728
Endが24までなのか25や26もあるのか、それとも24の次は1なのか確実じゃないのでその辺考えて修正してみます
やっぱりタイムスタンプに変換した方が短くなりますか？
あと、727のインポートでtimedeltaが抜けてました

2025/02/22(土) 14:22:19.90

print(datetime.now())
これの出力が
2025-02-22 14:20:40.735896
これになるのが嫌
秒を整数にしてくれたらそのまま使えるのに

2025/02/22(土) 15:29:44.08

何度もすみません
こうなりました
今のところt_startよりもt_endが小さいとエラーになります

https://techiedelight.com/compiler/?119b

2025/02/22(土) 18:46:10.84

pandasなら+“:00”してHH:mm:ss形式に揃えれば25:00や26:00でもパースできるけど簡単な処理だから自分で計算すればいいんじゃないかと思う

def parse_as_minutes(hhmm):
　hours, minutes = [int(x) for x in hhmm.split(':')]
　return hours * 60 + minutes

2025/02/22(土) 18:52:17.77

そんなのを毎回作ってられない
2回くらいは作る
3回目あたりで、本腰入れて部品化する

2025/02/22(土) 23:02:04.13

>>731
https://techiedelight.com/compiler/?96ec
これじゃ駄目なのか？

2025/02/22(土) 23:31:26.22

劣化しとるやないかーい

2025/02/23(日) 09:47:38.74

個人レベルで機械学習学んでも意味無いですかね？
例えば競馬予想aiを作りたいとして
しかし、けっきょくのところデータがないと、学習モデルだけあっても意味ないですもんね

競馬なら馬場状態を数値化したデータというのがないと、学習させられないですよね

2025/02/23(日) 10:33:41.64

>>730
そのくらいは標準で簡単に出来るだろ

2025/02/23(日) 10:36:52.09

>>736
自分で学習すりゃいいじゃん
データなんていくらでもあるんだし

2025/02/23(日) 11:58:59.62

>>736
他人の後追いするぐらいなら他人のシステム使えばよい

競輪なんて放送でAI予想の倍率出しながら中継してる

2025/02/23(日) 12:29:42.21

オッズの計算に投票だけではなくAI予想も加味したら、
面白さと利益率が上がるのでは

2025/02/23(日) 13:11:05.65

>>739
例えばバンクのホコリっぽさとか、選手の体調とか、そういった不確定要素ってデータがないですよね
なので、公式のデータ以外ないとするなら、あまりやる意味がないのかなと

2025/02/23(日) 13:17:20.60

確率が計算できて、オッズがその確率通りならば、どこに賭けても期待値は同じ
実際には、確率とオッズに乖離が発生する
そこに着目して、確率の高いところではなく、期待値の高いところに掛けると儲かるかもしれない

2025/02/23(日) 14:34:58.45

>>741
競輪AIだと雨が降ってると硬い結果になる

選手が雨の中危険な勝負して事故ったりしたくないんだろ

2025/02/23(日) 15:42:44.26

early continue 便利だな
行は増えるけどネストは浅い方がいいので積極的に使おう

2025/02/23(日) 16:11:59.81

>>744
横からだけどサンクスこれいいな

2025/02/23(日) 16:59:33.82

そんな言い方があるんだな
同じように関数で場合分けごとにさっさとreturnしてるけど
これもearly returnっていうのを知らなかった

2025/02/23(日) 17:13:57.05

例えばループで文字列を処理していて
m = re.search(pattern, str)
found = m.groups()[0]
これだと見つからない時にエラーになる

で、
if m :=
にしたりするけど、見つからなかったら飛ばしたいなら、
else:
　continue
になって、なんか変

最初から m = のままで、
if not m:
　continue
を付ければすっきりする
セイウチは絶滅の方向で

2025/02/23(日) 18:43:24.49

それ最初からelse: continue必要ないじゃん

2025/02/23(日) 19:01:50.10

elseをほっとくと、foundの中身が不定になってしまう
事前にNoneを入れておいたりして、後の処理でNoneなら飛ばす
みたいなことになる
そんなことするくらいなら、continueしてしまった方が後腐れない

2025/02/23(日) 19:46:23.76

>>709
Unityがゲームしか造れないという考え方は改めるべき

2025/02/23(日) 19:48:54.69

re.findall(pattern, str)

2025/02/23(日) 20:05:27.12

もしかしてfindallって全ての点でsearchに勝ってる?

2025/02/23(日) 20:54:18.71

なんでだよw
めちゃくちゃ要領悪いな

2025/02/23(日) 22:37:16.02

>>749
gotoを多用しそうな人発見

2025/02/23(日) 23:03:58.66

pythonのreはAPI設計に難があるよね
他の言語から戻って来るたびに仕様の確認が必要

2025/02/23(日) 23:09:23.71

perlから来たからsearchばっかり使ってるけど、
findallの方がこなれてそうだな

2025/02/24(月) 05:49:40.37

>>750
tensorflowとかunityで使えるんすか(´・ω・`)

2025/02/24(月) 08:23:49.32

>>747
> 最初から m = のままで、
> if not m:
> 　continue
> を付ければすっきりする
> セイウチは絶滅の方向で

話題をよく理解していないのだけれど、
コロンイコールを使って、そのように論理を逆転してやればすっきりする、というハナシとも違うの?

if not (m := re.search(pattern, str)):
　continue

2025/02/24(月) 12:12:57.30

>>758
747じゃないがセイウチはどうもPythonicじゃない感ある
他言語のletみたいにスコープも閉じてないし

2025/02/24(月) 14:57:43.47

いくつかのパターンのどれかに合致する、みたいな時は
if m :=
elif m :=
elif m :=
みたいにしか書きようがない
パターン検査と結果取得を同時に書かないと、同じことを2回書くことになる

2025/02/24(月) 15:09:39.96

>>756
ほんとにperl使ってた？
gフラグ + リストコンテキストを真似したのがfindallなんだが

2025/02/24(月) 15:27:48.14

だからこそ、1行で決まった数キャプチャーする時はsearchで、
全体からいくつあるか判らないけどあるだけ取ってくる時はfindallという使い分け

という設計だったけど、
1回しかマッチしないと判っててもfindallして[0]だけ使う方が使いやすいっていう