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/03/08(土) 15:24:08.77

>>866
>パスを切る＝ディレクトリを作る
パスを切るのはディレクトリを作ることではなくない？

2025/03/08(土) 15:45:23.76

パスやエイリアスを切るのは道を切り開くという意味じゃない？
>>868で挙がっている「割譲する」というニュアンスの切るとはまた違うと思う

2025/03/08(土) 15:57:23.70

PATHを切るは確かに言うな
PATHを通すと同義の奴じゃないかな
作成するのはディレクトリやフォルダで、PATHはフルパスのことなので、
それ自体を作成したりはしない

2025/03/08(土) 16:22:09.63

お前ら時代を考えろ
コマンドライン時代だ
/でディレクトリの区切りを示すやろ
この事からパスを切るって言うんだよ

2025/03/08(土) 16:28:31.93

Python勉強したかったらgithubのオープンソースと睨めっこしてこい。こんなとこでレスしても池沼mac信者しか沸かんぞ

2025/03/08(土) 17:08:49.84

別れろ切れろはブランチの時に言う言葉、今のあたしにはいっそ kill と言っておくんなまし

2025/03/08(土) 17:37:17.94

言葉の意味を知らないで使い続けた慣用句の扱いだから
ゼロックスしておいておじさんが直すとも思えない
かと言って的は射るものですよ的な指摘も無粋

現場で仲良くやれればいいんじゃね？
意味はある程度通じているわけだし

2025/03/08(土) 17:38:34.41

何を発狂してんのよこのゴミは
「ブランチを切る」が現場で当たり前のように使われることを知らずに赤っ恥かいたから
正当化しようと暴れてるのか
見苦しい

2025/03/08(土) 17:53:41.60

どっちかというと、ローカルな用語が一般で通用しなくてショック受けてる、が正解だな
これ方言だったの?的な

2025/03/08(土) 20:56:09.68

すいません>>819わかる人いたら教えてください
gitスレでも聞いたんですが、CUI vs GUIみたいな糞どうでもいい話ばっかりしててあいつらはもう駄目です

2025/03/08(土) 22:42:06.31

>>878
gitのlogやreflogを確認するか
Syncボタンを押した時に発行されるgitコマンドが表示されるパネルを開いてから
もう一度試せばいいんじゃない？

gitというより聞くならVSCodeスレじゃないか

2025/03/08(土) 22:45:58.02

>>877
公式サイトにある日本語訳でもブランチを切るという表現が多々出てくる
日本語訳が出来た2009年当時からずっと変わらず

2025/03/08(土) 23:43:37.51

>>857
作る、作成するでいいのに変な日本語を使い続けるのは老害

2025/03/08(土) 23:44:49.47

>>880
樹木の枝を切るという世間一般のイメージに引きずられているだけ

2025/03/09(日) 01:03:40.90

『「的を得る」が間違い』は間違い

2025/03/09(日) 01:50:12.00

>>878
その質問ChatGPTに聞いてみた？

2025/03/09(日) 08:04:54.92

>>884
pullしてpushって言われた
>>879
確かに

2025/03/09(日) 13:04:54.25

gptにコード書いてもらうのが一番

2025/03/09(日) 16:02:37.71

>>819はこれかな？
https://github.com/microsoft/vscode/issues/137686

2025/03/09(日) 20:36:14.62

単純にVSCodeがorigin/masterにpushしてるだけだった
同じブランチでいくつかcommitして、sync changesボタンでたからマウスオーバーしたら、Push 4 commits to origin/masterってでたから
まんまmasterブランチにpushしてるだけだった
あとreflogにはVSCodeのSyncボタン押した時のログは残ってなかった

2025/03/10(月) 12:17:45.33

連番のtxtファイルの中に物体名とそのXY座標値がスペース区切りで格納されてるんだけど
for文でぐるぐる回して各物体ごとに前のファイル内に書かれてる座標値との差分を連続で出したい時ってどういうやり方するのがスマートだろうか
pandas使ってDFに入れるのが早いのかなあ

2025/03/10(月) 14:54:26.98

それのやり方は知らんけど
pandasよりpolarsの方が速いよ

2025/03/10(月) 16:04:01.44

>>889
プログラム設計時に必要になる情報と一緒だけど
前提となる入力と出力の仕様をもう少し明確にしないと
どういうやり方が適切なのかはわからないよ

2025/03/10(月) 16:11:52.34

>>888
ローカルとリモートで互いに足りない部分をpull/pushして結果を同じにしてるんじゃないの？

2025/03/10(月) 18:45:12.16

git push origin hoge:masterのように
リモートは問答無用でmaster指定してるってことだろうけど
ローカルのhogeをリモートのmasterに直接pushするのが
あまり一般的なワークフローではないんじゃない？

2025/03/10(月) 19:26:13.81

pandasとかはファイルは一つでそこに行と列がたくさん、というデータを想定してるから、
ファイルがたくさんある時点で違う気がする

複数ファイルを一つのdfに結合する部分を自分で書けばpandasで処理できるだろうけど、
pandasで楽になりそうな処理にも思えない

2025/03/10(月) 19:40:26.55

巨大なデータってオンメモリで終わるまでソワソワしながら待つの？
それとも中間ファイル残しながら失敗したらそこから再開とか？

2025/03/11(火) 08:25:30.10

場合によるよね。
やったことないけどw

2025/03/11(火) 12:26:00.83

>>895
スワップ使いまくるからオンメモリとは言えないかもしれないけど大きめのプログラムのフルコンパイルみたいなのはソワソワしながら待つ

途中まででコミットして再開可能なデータ処理は中断の可能性や再実行にかかる時間、プログラムの複雑化度合いなんかを加味して方針を決める

2025/03/11(火) 19:24:18.03

makeみたいな仕組みにしとけば、失敗したところからやり直せる

2025/03/11(火) 19:40:15.54

大規模な処理の場合はSparkみたいな分散処理フレームワークが障害時の途中からの復旧とかを担保する
一方で、アドホックな作業の耐障害性はあまり問題にされることはない
いつも中途半端な実験ばかりで何一つ金になる成果を出さない自称データサイエンティストがノートブックで手元でチマチマやってる程度の作業なんて、
パーになったところでビジネス視点では何の影響もないからね

2025/03/11(火) 20:32:11.49

アドホックな作業？

2025/03/12(水) 10:36:16.02

ビルメンだから業務効率化とかはできないけど趣味で Python 勉強中

2025/03/12(水) 10:36:17.25

ビルメンだから業務効率化とかはできないけど趣味で Python 勉強中

2025/03/12(水) 16:55:28.43

巡回ロボを作るとか。

2025/03/12(水) 18:02:38.98

エレベーターの劣化チェックが良いな

2025/03/12(水) 19:04:57.91

巡回ロボいいね
エレベーターのチェックって画像認識？

2025/03/12(水) 19:42:29.70

boto3とrecognitionでできそうやな

2025/03/13(木) 08:05:57.02

そんなもん1年後くらいに汎用マルチモーダルAIに自然言語で指示するだけ

2025/03/13(木) 10:46:41.91

どこまでプログラミング勉強すべきなんだろうな
AIのコーディング能力かなり上がってるからがっつり自分でかけるようになる必要はないけど、まるごと書いてくれるわけではないし少し修正しようって思ったら丸ごと書き直さないといけないから効率悪いんだよな
基本をさらっとやって、クラスだかモジュールだかの設計ができるようになればいいのかな

2025/03/13(木) 12:01:16.03

画像解析は汎用AI化が出遅れてる分野なので、PyTorchとかでシコシコ自前でやりたい人にとってはラストリゾート
とはいえ自動運転や医療画像みたいな絶対安全な分野を除けば向こう2年くらいの命だろうな

2025/03/13(木) 12:54:57.01

AIエディタを使いこなせるか
これが最も重要

2025/03/13(木) 17:05:12.30

耳コピの分野が出遅れてるんだよな
ピアノ音源限定でノイズが無ければ、音の高さまでは割と正確に判断する
でも小節の切れ目は判らないので楽譜化はできない
複数の楽器混在とかはまだ全然

2025/03/17(月) 11:16:03.53

pythonの文法って簡潔すぎてわかりにくいの俺だけ？
for i in range(10)
よりも
for (i = 1; i < 10; i = i + 1)
の方がわかりやすい
C言語から始めたせいかもしれんが

2025/03/17(月) 11:23:32.88

for i in range(10)　←配列０～９の左から1つずつiに代入
まあわかる
if i in ng_numbers　←iが配列ng_numbersに入っていたら
？？？

2025/03/17(月) 11:30:36.89

>>913
英語で考えりゃ自然

2025/03/17(月) 11:50:52.82

>>914
そりゃ英語で考えればそうやがどういう処理しとんねんってなる

2025/03/17(月) 12:21:38.78

pythonで分かり難いのは、なんてったって str.encode() と bytes.decode() だわ。
型変換を符号化復号化と称すのもどうかと思うが、バイト列を文字列にするのが何で復号なのか不思議でならない。

2025/03/17(月) 12:45:47.58

Pythonがどういう内部表現で文字列を表現してるかは一旦置いておいて
目に見える図形・グリフとしての文字の列をエンコードしてバイト列にするのがstr.encode()
エンコードされた結果のバイト列を文字の列に戻すのがbytes.decode()

わかりにくいのは確かだけど間違ってはいない

2025/03/17(月) 13:35:59.30

rangeとか lenは使わない
オブジェクトがあるんだから、そのものを渡そう

2025/03/17(月) 14:16:08.27

>>913
どゆこと？
for i, ng in enumerate(ng_number)
これのことではなくて？
ng_numberの条件で飛ばすなら内包表記使って

for x in [ng for ng in ng_number if ng_number[何か] == 何か]

とかの話？

2025/03/17(月) 14:28:12.40

同じ”in”で使われ方も似てるけど文法的には別の”in”
https://docs.python.org/3/reference/compound_stmts.html#for
https://docs.python.org/3/reference/expressions.html#membership-test-operations

2025/03/17(月) 15:27:05.92

pythonのfor文は他の言語でいうところのforeach文だな
シェルスクリプト（sh系）もそうで、これから入ったのでこちらのほうが馴染む

2025/03/17(月) 18:25:36.28

CからC++とか進んだけど特にforで何とも思ったことないな

2025/03/17(月) 18:35:25.17

生成してもらってるから
forの意味すら知らん

2025/03/17(月) 18:59:30.26

FOR X = 0 TO 9 (BASIC)
for x := 0 to 9 (pascal)
for (x = 0; x < 10; x++) (C)
なんかどんどんforの意味からずれていく

for x in range(10)
これが正解

2025/03/17(月) 20:11:45.28

for i in range(10)で0～9のループってのがアホらしい
0から9と明示している言語が自然

2025/03/17(月) 20:35:11.55

rangeは直前までのrangeオブジェクトを返す、と慣れればそれでいいじゃん

2025/03/17(月) 20:42:27.97

range(1, 11) みたいに複雑になると、もうこれは
for (x = 1; x < 11; x++) から数字を抽出したものになってくるけど、
普通は先頭は0なので本質的には要素数を表している
0から始まって当然の頭になれば自然に見える

2025/03/17(月) 21:19:59.96

>>926
seq コマンドといつもごっちゃになってまう...

>>> tuple(range(2))
(0, 1)
>>>
$ seq 2
1
2
$

2025/03/18(火) 01:35:19.58

個人的には他言語のforeach相当しかないのはかなり好きなポイントだな

2025/03/18(火) 01:59:29.87

>>912
Pythonはこの書き方が便利だとか、わかりやすいなどとは思えない構文が多い

2025/03/18(火) 03:15:42.25

>>912
pythonのforは他言語の
foreachに近い
書き方だからなあ

で、foreachも
foreach 要素 in 配列名
タイプの書き方の言語と
foreach 配列名 as 要素
タイプの書き方の言語がある

2025/03/18(火) 03:23:10.83

perlはけっこう自然言語っぽい構文も追加で備えてるな

2025/03/18(火) 07:41:55.04

繰り返し処理に for というキーワードを選んだのが間違いなのでは
BASICが最初なのかな
てっきりFORTRANだと思ってたけど、DOなんだよな
DO X = 0, 9
それはそれで変だけど

一定範囲をスキャンするとか、要素を全部舐めるとか、
そういうニュアンスの単語が無かったんだろう

2025/03/18(火) 08:08:58.90

sweep

2025/03/18(火) 10:39:43.40

#include

2025/03/18(火) 11:03:33.56

BASICなわけねーだろw その辺は全部ALGOLだよ
なかったもクソもforには反復とかいくつずつみたいな意味が元々ある
ていうかそもそもはドイツ語だったかなんかのはず

2025/03/18(火) 17:06:54.31

ALGOLは使ったことないなあ
FORTRANで採用を見送られたのに、その後また復活したのか

ステートメントが前置詞というのはやっぱり筋が悪いって

2025/03/18(火) 18:15:32.73

数式の英語での読み方から来てるから英語で数学を習った人にとっては何の違和感もないはず

2025/03/18(火) 22:08:58.63

ALGOL（含む68）辺りにリアタイで手を出していたら、ミニコン使いやで。
インターフェースがトラ技別冊だった頃を知っているかと。

基準画像「某レナさん」のグラビアを見た事があるんじゃね？

2025/03/18(火) 22:14:52.79

島倉千代子を推してた口だな

2025/03/19(水) 09:12:58.29

ALGOLはイスラムが語源
FORTRANはFormulaTranslator

2025/03/19(水) 18:59:21.09

alの部分は定冠詞だけどな

2025/03/20(木) 08:55:27.85

def func(param): は
def func(param: str): なのに、
def func(param='value'): が、
def func(param='value': str): でなく、
def func(param: str='value'): なのは、おかしいだろ。責任者のアホ。

2025/03/20(木) 10:13:00.87

>>943
def func(param): が
def func(param: str): だからこそ、
def func(param='value'): は、
def func(param='value': str): でなく、
def func(param: str='value'):

型ヒントは変数の型をチェックするために存在してる

2025/03/20(木) 10:16:14.83

param: str='value'
が
param: と str='value' に分かれて見えてるんだな
そうではなくて
param: str というかたまりに 'value' を入れている

2025/03/20(木) 10:19:49.89

コロンやらスペースを乗り越えた先に左辺値があることに脳パーサがバグるのは判る

**デフォルトの名無しさん** (JP 0H8b-0naI) · 2025/03/20(木) 10:33:23.18

型ヒントって必要？
使わない人が大半だと思うんでプライベートなコード以外には使わないでほしい
仕事で型ヒントが大量にちりばめられてるるコードのメンテナンスなんてやりたくない

2025/03/20(木) 11:00:47.02

逆では
みんなの頭がつながっていないからこそ必要
IDEの支援ももらえるし

2025/03/20(木) 11:09:51.36

型は制約されてないし、だからこそのオブジェクト指向だけど、
実際は入る型なんか決まってるケースが大半なのでヒント止まりになる
正式なコメントの書き方

2025/03/20(木) 11:16:01.10

型ヒントないとやだわ

2025/03/20(木) 13:38:22.10

>>947
いらない
そもそも高度な型を書けないから無意味
エディタで補完されるしそれで十分

2025/03/20(木) 13:39:45.20

本当に型が欲しいならTypeScriptなりRust使うっての

**デフォルトの名無しさん** (JP 0H8b-0naI) · 2025/03/20(木) 14:29:39.20

>>952
だよねえ
必須でもない型機能なんて混乱をもたらすだけだと思うわ
この運営の迷走ぶりがPython凋落のきっかけになるんじゃないかと危惧している

2025/03/20(木) 14:55:26.24

自作コードは好みだろうけど、
公式ドキュメントは記述を対応させて欲しい。

> str.split(sep=None, maxsplit=-1)
https://docs.python.org/ja/3.12/library/stdtypes.html#str.split
なんて表記じゃ、sepに区切文字を入れるのか、複数の区切文字の配列を入れるのか分からない。
実行結果も、リストか返るのか、独自型が返るのか、或いは返さずに REPLY. 変数に結果をセットするのか分からない。
この例は split() なので想像つくのだけど、謎機能は入出力も謎で泣ける。

2025/03/20(木) 17:38:19.11

型ヒントはコメントで書く
3.4（XPラスト）用をメンテしなくちゃならないので

2025/03/20(木) 18:15:32.43

pyenv pipx poetryをos丸ごと捨ててuvに切り替えた
poertyって依存のバージョン解釈がバグってることあったけど、uvはちゃんとしてるな
アストラルがanacondaみたいにいきなり発狂しなきゃいいけど

2025/03/20(木) 18:21:06.92

いつかいいのができるまで、バージョン管理なしでやってる

2025/03/22(土) 14:27:58.31

Rust の crates と Cargo は良さげだけど微妙
Python で真似するの流行り過ぎて心配

2025/03/22(土) 19:43:37.05

>>956
マジか
もうanacondaから卒業すべきだな

2025/03/22(土) 21:27:24.19

pythonのバージョン管理よりも、コードの構成管理したい
いろんなとこにコード書き散らすから、svnでもgitでも管理できない

2025/03/22(土) 22:06:39.66

バージョン管理ツールで作成した環境の一覧がわかればいいの？
ならpyenv-virtualenvとか
zoxideやautojumpもいいかも

2025/03/22(土) 22:19:14.19

uvとruffにした
ネットの情報古いのばかりでここにたどり着くのがすごい大変だった
素がpythonじゃないのでいきなりインストールして環境作れるのも楽
そのうち有料になっても金払っていいレベル

2025/03/22(土) 22:20:25.56

uvはlockまでちゃんとクロスプラットフォームなのがでかい
どこまで信用できるかは分からないけど、今のところ問題はないので
新しく書いたやつを中心に徐々に移行してる

2025/03/23(日) 22:26:19.29

>>736
馬場状態とか、、、数あるファクターのただの一つに過ぎないよ。
本気でやるならjvlinkで仕様書見てどんなデータがあるか眺めてみるといい。
どうせ挫折するだろうからあまり深く言わないけど、未来を予想するのと、ギャンブルで勝つのは二つ分析目標があると考えた方が良い。
勝率と回収率が逆相関になることがわかったらそこが沼の入り口だよ。
あすすめは、まず人気と回収率のデータを取ってみて、競馬は１番人気を買うと絶対に回収率がマイナスになり、最低人気を買っても同じ。これは何故かを考えることをお勧めするよ。

2025/03/24(月) 08:15:13.03

ギャンブルにAIを使おうとするなんてばかにすることよな
働けよ

2025/03/25(火) 15:35:13.74

自分は静的型検査はどっちかといえばある方がいいかな派（でも自分ではあんまりやっていない）なんだけど、typingモジュールの内容は盛り沢山すぎて、なかなか腰を据えて勉強する気になれないな。たぶん、型に一家言ある世界中の人が議論して仕様を作っているんだろうとは思うけど。
もう数年して仕様が落ち着いてきたら、たぶん解説本が出ると思うので、それを読んで勉強しよう。ロバストPytnonは結構面白かったので、その延長上で型アノテーションの説明に焦点を絞ったようなやつが出れば面白いと思う。

2025/03/25(火) 21:47:04.49

ハイパーモダンPython改訂版出してくれ

**デフォルトの名無しさん** (JP 0H26-z40Z) · 2025/03/26(水) 04:22:01.80

>>967
お前が作るんだよ
オープンソースだから改変し放題