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/14(金) 00:52:13.45

いや、言語設計の話ね
引数の列みたいなタプル的なもので許されてるなら、
タプルでも許されるような規則になってる方がコンシスタント

それを許すと別の問題が生じるなら仕方ないけど、
特にそんなのがあるような気がしない

2025/02/14(金) 01:53:56.51

54氏に絡んだ私が馬鹿だったみたいだね

**デフォルトの名無しさん** (JP 0Hc6-nRXM) · 2025/02/14(金) 07:12:48.02

型アノテーションはどう考えてもコードを冗長にするだけの効果しかなかった
次期バージョンからは廃止して欲しい
アノテーションありとなしのコードが混在する世界は誰も得しない

2025/02/14(金) 07:34:58.64

01氏は相変わらずだのう
よく知らんけど

2025/02/14(金) 12:40:51.82

型アノテーションしないとvscodeでメソッドとか補完してくれないじゃん～

2025/02/14(金) 12:47:27.45

>>630
これはそう
型の表現がゴミなのでその型意味ある？ってやつばっかでノイズにしかならん
tsみたいに別の処理系として作るべき

2025/02/14(金) 13:23:14.36

>>625
>xs: Tuple[Optional[int]] = 1, 2, 3
これじゃダメじゃん
ellipsis忘れてた

2025/02/14(金) 19:00:49.38

どうせdataclassで型指定が必須になる

2025/02/14(金) 22:20:16.99

age : int = int(9)
右のint()は不要ってことだよね
今だと全部上の文にしようとしていました

2025/02/14(金) 22:27:43.41

型なんかコンテキストに任せるperlの時代がまた来ないかな
厳密なのはCに任せておいて、手抜き派は限界まで脱力しないと

2025/02/14(金) 23:33:39.76

perlは$@%で変数の中身と参照方法の手がかりがあるの楽すぎる
しかも記号の切り替えでアクセス方法も切り替えられる
初心者の俺だけかもしれないけど

2025/02/15(土) 00:03:38.48

>>638
dollar_とかatmark_とか変数に付ければいいのでは?

2025/02/15(土) 00:09:45.51

指し示す時は%varとか@varだけど、使う時は$var{}とか$var[]なのは、
普通に混乱するよな
同じ名前が使えるのはやばすぎるので、敢えて使わないようにしてた

2025/02/15(土) 00:24:38.71

>>636
右のint()はintにキャストしたい時に使う
左のintも大半の箇所では不要

数値リテラルで初期化する場合に明示的に型を書く必要があるケースはあまりない
上で書かれてるdataclassのfieldなんかは例外

2025/02/15(土) 01:12:51.65

type aliasでwin32 apiみたいに狂ったようなヘッダーファイルのimportとかになったら嫌だな

2025/02/15(土) 02:36:03.74

型ヒントないとやだやだ

2025/02/15(土) 03:01:40.24

>>641
ありがとうございます

2025/02/15(土) 03:03:06.76

>>640
なるほど

2025/02/15(土) 09:21:15.19

一括代入の左辺って、正確にはタプルではないよね。タプルに引き付けて考えるより、代入文の構文の1類型として整理しておく方が良いんじゃないかと思うが。

2025/02/15(土) 10:22:34.31

>>> x = a, b = 2, 3
>>> type(x)
<class 'tuple'>
よくわからんな

2025/02/15(土) 10:51:26.01

>>646
タプルとおもっていたが、正確には何なの?

2025/02/15(土) 13:22:10.39

タプルだよ
a, b = 1, 2 は(a, b) = (1, 2)と同じ

内部的にも一旦タプルとして扱われてunpackingが行われる
[a, b] = 1, 2とかにすれば左辺はリストになるけど
括弧省略したカンマ区切りの場合はタプル

2025/02/15(土) 14:36:18.19

たとえば、タプル (3, 4) では、（要素0の）3を指すポインタと（要素1の）4 を指すポインタとはメモリ上隣接した位置に配置されるけど、
a = 1 b = 2 の後に a, b = 3, 4 と一括代入をしても、（一旦タプルが作られるのかどうかはともかく）そういうことにはならないんじゃない？

*[a, b], c = 1, 2, 3 のようないわゆるスター代入も、イテラブルのunpackではないと思うし。

2025/02/15(土) 16:45:49.40

return文の複数値の返却もタプルだけど、
なぜかカッコを省略することが多い
まぁ、あくまでカンマがタプルの肝だからということか

2025/02/15(土) 17:05:56.61

リストの内包表記の[]を()にすると、
タプル内包表記ではなくジェネレータ内包表記になる罠

2025/02/15(土) 17:06:49.88

カッコの用途と意味が多くて初学者にはきついと思うわ
( ) はタプルとGenerater
{ } は辞書と集合
[ ] はリストと内包表記

2025/02/15(土) 17:09:49.95

空の集合で初期化しようとしてs = {} とか書いてしまう罠
(1,) とか class_ とか苦し紛れいろいろ

2025/02/15(土) 17:33:56.56

丸括弧は関数・クラス等の呼び出し、角括弧はリスト、波括弧は辞書および集合。
リストと辞書と集合には内包表記があって、generator式は内包表記の仲間。
そうやって整理する分には、（単要素タプルの書き方がちょっと不格好なところを除けば）そんなに違和感はないけどなぁ。
辞書についてリテラル表記は波括弧なのに参照は角括弧なのはちょっと引っかかりを憶えないでもないけれども、これは他の言語でもそうだし。
他の言語と比べて特に複雑ということはないと思うけど。

むしろVBAみたいに、配列の添字指定に丸括弧を使わされたりする方が嫌だわ。

2025/02/15(土) 19:13:45.78

immutableなタプルの要素にはそもそも代入ができないはずなので、それだけでも一括代入の左辺がタプルでないのは明らかなのでは。
一括代入の左辺に丸括弧や角括弧が使えるのは、入れ子構造になっているときにその構造を明確にするために過ぎず、リストやタプルとは全く関係ないって考えた方が分かりやすいように思う。

2025/02/15(土) 23:10:55.08

左辺と右辺で違いがあるのは当たり前
右辺の値としてのタプルと左辺の言うなればパターンとしてのタプルが
全く同じように評価・実行されるわけがない

タプルじゃないとしたほうがわかりやすいならそうすればいいとは思うけど
言語的には左辺の(a, b)もタプルという扱い

2025/02/15(土) 23:12:46.33

ASTで見るとこうなる

import ast
expr = ast.parse("a, b = 1, 2")
print(ast.dump(expr, indent=4))

Module(
　body=[
　　Assign(
　　　targets=[
　　　　Tuple(
　　　　　elts=[
　　　　　　Name(id='a', ctx=Store()),
　　　　　　Name(id='b', ctx=Store())],
　　　　　ctx=Store())],
　　　value=Tuple(
　　　　elts=[
　　　　　Constant(value=1),
　　　　　Constant(value=2)],
　　　　ctx=Load()))])

2025/02/15(土) 23:29:56.42

a = 1
b = 2
t = (a, b)
print(t) # (1, 2)
a = 3
b = 4
print(t) # (1, 2)

変数でもそのオブジェクトでもなく、
中に入ってるものでタプルを作る
だから、(a, b) がタプルというのも不正確

2025/02/16(日) 00:53:20.10

>>657-658
ASTでタプルとされているからタプルなのだ、それが言語上の定義なのだと言われればそうですかと言うしかないのだけれど、メモリレイアウトがどうなっているかは気になるな。a, bはメモリ上隣接した位置に配置されるのか、それとも、離れた位置に配置されるけれども代入文の左辺である限りはタプルと呼んでいいということなのか。

2025/02/16(日) 07:14:20.57

メモリ上隣接はCPythonの話？
それこそはいそうですかだけど

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
みたいに秒に変換して引き算が正解じゃない？