Pythonのお勉強 Part75 (989ﾚｽ)
上下前次1-新
965(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 258f-MlPs) [sage] 2025/10/04(土) 13:03:57.65 ID:lfhYKLud0(2/4) AAS
>>964964(1): デフォルトの名無しさん (ﾍﾞｰｲﾓ MM2b-G6c+) [sage] 2025/10/04(土) 11:24:37.65 ID:Lrd6UCHyM(1/2) AAS
>>962
raiseはプリミティブな操作だから
raiseが関数だったとして、じゃあraise関数をどうやって実装する?
結局Pythonのインタプリタに直接組み込むしかないだろう。だから意味がない。
assertについては、assertを無効にする場合は式の評価自体を飛ばさなければならない。そんなことは普通の関数では実現できない。
で指摘されている点は、インタプリタ上で特別扱いしないと対応できない（通常の関数の枠内では処理できない）というのは分かるんだけど、逆にいうと、インタプリタが特別扱いをするのであれば、関数呼び出しのインターフェイスをすることもできなくはないわけでしょう。
assert文の2つ目の式にAssertionErrorに渡す引数を指定するという構文は直感的に分かりにくいなと以前から思っていて、仮に関数呼び出しのインターフェースで呼べるならそんなに違和感ないなとちょっと思っただけ。積極的にそうした方がいいとかそうすべきと主張するつもりはないよ。
966: デフォルトの名無しさん (ﾍﾞｰｲﾓ MM2b-G6c+) [sage] 2025/10/04(土) 13:49:26.07 ID:Lrd6UCHyM(2/2) AAS
>>965
Pythonだと通常の関数呼び出しになってたら特別扱いは難しい
別のraise関数が定義されてるかもしれないからな
じゃあraiseという名前だけをキーワードとして特別扱いするか?それraise文と何が違うの?
ってこと
967(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 25c4-MlPs) [sage] 2025/10/04(土) 14:08:02.28 ID:lfhYKLud0(3/4) AAS
仮に特別扱いするなら、raise を一種のキーワードとすることになるんだろうね。raise文との違いは構文。もともとraise文の構文ってちょっと分かりにくくないかというのが元の発想だからね。
どちらかというと、raise文の構文は直感的にちょっと分かりにくいので関数呼び出し風の構文糖があったら良かったのに……という方が言いたいことに近いかもしれない。
968: デフォルトの名無しさん (ﾜｯﾁｮｲ 0d54-DOAI) [sage] 2025/10/04(土) 14:18:48.32 ID:ZS4Jz9di0(1/2) AAS
そんな形式上のものはシンタックスシュガーでどうにでもなる
969: デフォルトの名無しさん (ﾜｯﾁｮｲ 3d01-UAuC) [sage] 2025/10/04(土) 15:12:23.29 ID:cv59dmAz0(1/2) AAS
仮にraiseを関数化するとしたらビルトイン関数になるわけでキーワードとして特別扱いするのとは違う
ビルトイン関数を別のraise関数で上書きしたならその時の動作は上書きした人が責任を持てばいい
ただraiseとassertを同じカテゴリで話すのはどうかと思う
raiseはreturn, break, continue, yieldなどと同じcontrol flow statementなので通常関数とは別のカテゴリとして扱うのが言語を使う側にとっても作る側にとっても自然かつ楽
raiseと違いassertはprintなどと同じでビルトイン関数のほうが使う側には自然
コンパイラを改良する労力をかけたくなかったからステートメントのままなんだと思う
970(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 25c4-MlPs) [sage] 2025/10/04(土) 15:56:42.08 ID:lfhYKLud0(4/4) AAS
assert と raise とで区別すべきというのは同感（>>967ではボケていてraiseって書いちゃっているけど、965に書いたとおりこの話は基本的にはassertを想定している）。
ビルトイン関数にするかキーワードにするかというのは正直そんなに意識はしていなかったかな。仮にビルトイン関数にするとしても通常の関数とは異なりインタプリタによる特別扱いが必要なら、いっそキーワードにしてしまう方が簡単なような気もするけど、まぁ、どちらでも良いのかなと。
Pytnonの場合、yieldのような前例があるから同じ構文の中の一定の場合だけを特別扱いするということに比較的抵抗がない文化なのかなとも思うけど、assert に関しては文のままでいい（処理系に手を入れてまで関数っぽいインターフェイスを提供する必要はない）というのが現時点までの開発陣の判断ということよね。個人的にはちょっと残念だけど、まぁ仕方ないのかなとは思う。
971: デフォルトの名無しさん (ﾜｯﾁｮｲ 0d54-DOAI) [sage] 2025/10/04(土) 16:09:30.50 ID:ZS4Jz9di0(2/2) AAS
raiseのノリでexitと書いて何故か終わらない
972: デフォルトの名無しさん (ﾜｯﾁｮｲ 3d01-UAuC) [sage] 2025/10/04(土) 17:51:28.50 ID:cv59dmAz0(2/2) AAS
>>970
今後の拡張でコンパイラが利用可能なアノテーションを関数に付与できるような仕組みでもできればそれを活用してassertを関数化する可能性は個人的には十分あると思う
逆にassertだけのためにそういう仕組みを追加したり内部的にもassertという名前縛りで関数呼び出し箇所のbytecodeを出力しないようにする変更は費用対効果的にまずないと思う
973: デフォルトの名無しさん (ﾜｯﾁｮｲ 43de-MlPs) [sage] 2025/10/04(土) 19:23:00.85 ID:MKE3mvtR0(1) AAS
まぁ、yield と assert とでは色々違うもんね。
974(1): デフォルトの名無しさん (ﾜｯﾁｮｲ ae60-9taF) [] 2025/10/05(日) 05:42:31.29 ID:Wx5pDard0(1) AAS
仮想環境をゴリゴリ作るという観点からanacondaは優秀だと思う。
それ以外は…
975: デフォルトの名無しさん (ｵｯﾍﾟｹ Sr75-SPhl) [] 2025/10/05(日) 07:52:01.85 ID:75RY5Ni2r(1) AAS
俺はminiconda
976: デフォルトの名無しさん (ﾜｯﾁｮｲ ae02-GsXg) [] 2025/10/05(日) 08:44:09.44 ID:/6a5ZxIp0(1) AAS
時代はUV何ですよ!!(´・ω・`)
977: デフォルトの名無しさん (ﾜｯﾁｮｲ 3133-gAFJ) [sage] 2025/10/05(日) 09:26:26.39 ID:DxOKijn50(1) AAS
>>974
もうuvがいいぞ
978(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 0154-vC9d) [sage] 2025/10/08(水) 06:55:25.58 ID:lcCd82qT0(1/5) AAS
ファイル削除にimport osとかするのがなんか抵抗あったけど、
pathlib使ってるならp.unlink()で良かったんだな
979: デフォルトの名無しさん (ﾜｯﾁｮｲ 05f9-lCgs) [] 2025/10/08(水) 13:40:49.01 ID:XrXXkqZa0(1) AAS
unlinkって名前わかりにくい気がするけどそういうもんなんかな
980(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 0154-vC9d) [sage] 2025/10/08(水) 13:48:26.60 ID:lcCd82qT0(2/5) AAS
deleteとremoveの違い
deleteするとなくなってしまうけど、removeは消えるだけで実体はある
unlinkはもっと明示的にいつでも復活できそう
981: デフォルトの名無しさん (ﾜｯﾁｮｲ 762a-8Ckq) [] 2025/10/08(水) 14:07:17.26 ID:UyQ1K/rS0(1) AAS
>>978
なぜ
import os に抵抗があって
import pathlib には無いの?
982(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 0154-vC9d) [sage] 2025/10/08(水) 14:17:47.05 ID:lcCd82qT0(3/5) AAS
pathlibは神ライブラリだから
openするだけだとしてもPathオブジェクトにしとくと後々役に立つ
983: デフォルトの名無しさん (ﾜｯﾁｮｲ d5b5-ri6y) [sage] 2025/10/08(水) 20:10:03.79 ID:PPRPrFFf0(1) AAS
>>980
>>982はまだ個人の感想だけど平然とウソ書いてくるのがこわい
AIさんかな
984: デフォルトの名無しさん (ﾜｯﾁｮｲ 3115-jQt6) [sage] 2025/10/08(水) 21:22:40.69 ID:a5q/Ytzw0(1) AAS
スラッシュで文字列とPath結合できるの好き
985(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 0154-vC9d) [sage] 2025/10/08(水) 21:27:24.89 ID:lcCd82qT0(4/5) AAS
パスを文字列で持つこと自体が恐らくアンチパターン
986: デフォルトの名無しさん (ﾜｯﾁｮｲ 0a66-qIC/) [sage] 2025/10/08(水) 23:11:40.46 ID:DEFvJ9Zk0(1) AAS
ファイル操作が多い場合にはpathlibが便利なのかなとは思うんだけど、そもそもファイル操作自体あまりしないから、いつもpath =r'...' みたいな感じで文字列にしちゃっているわ。
987: デフォルトの名無しさん (ﾜｯﾁｮｲ 0154-vC9d) [sage] 2025/10/08(水) 23:14:49.71 ID:lcCd82qT0(5/5) AAS
読み込む用のファイルがあって、拡張子だけ変えたいとか、
ファイル名の部分に-oldと付けたいとか、別のディレクトリに同じ名前でコピーしたいとか、
そういう操作を正規表現とか駆使しながら頑張って文字列操作するのは、
めんどくさいし読みにくいしバグる
人間がやるべきではない
988: デフォルトの名無しさん (ﾜｯﾁｮｲ 7610-qIC/) [sage] 2025/10/09(木) 00:23:35.01 ID:YJJHW0Xm0(1) AAS
そういう処理が必要になったら、その時点で検討するって感じかな。もちろん、パスならとりあえずPathオブジェクトにしとけっていう流儀もあると思うけどね。
989: デフォルトの名無しさん (ﾜｯﾁｮｲ ee02-hOow) [sage] 2025/10/09(木) 22:53:20.67 ID:QQVMS2V+0(1) AAS
言ってしまえば「動けばよい」「分かればよい」だと思うが
扱おうとしているものを扱うための機能があるのなら、
それは使ってみたいじゃないの
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 1.633s*