Pythonのお勉強 Part73

2024/06/06(木) 08:48:10.07

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

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

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

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

2024/08/05(月) 19:42:50.14

>>370
速いとか遅いとか言っている人間とは縁を切れ

2024/08/05(月) 19:43:32.98

>>370
実際に時間がかかるものを作って比較するしかない

2024/08/05(月) 19:53:32.99

>>370
> 他

が何かによるんじゃないか。

2024/08/05(月) 19:58:12.02

>>370
確実に言えるのは初心者が気にすることではない

2024/08/05(月) 20:21:32.67

>>371-374
なんだ、そんなに体感するほどでないんだ
ネトゲのフレンドにPython勉強してるっていったら「あーPythonは簡単だけど処理速度が遅いからね」って言ってたから不安になった

2024/08/05(月) 20:31:36.33

0.01秒で終わっても1秒で終わっても人間からすれば同じだしな
他でなら1時間で済むものが100時間かかるなら考える

2024/08/05(月) 20:41:24.61

単純にやると100倍遅くていろいろ工夫しても数倍遅いことはある

2024/08/05(月) 20:53:20.49

>>376
それ結構ちがくね？？？？

2024/08/05(月) 21:03:47.56

>>375
処理速度を気にするような処理はPythonには不向きってことではある

2024/08/05(月) 21:13:21.36

pipでパッケージいろいろ使えるし
手軽でいいぞpythonは

2024/08/05(月) 21:13:41.24

>>375
そんなド素人の話なんか無視してくれ

2024/08/05(月) 21:14:56.84

>>379
オンボロPC上で動かすのか？

2024/08/05(月) 22:59:18.56

Pythonで書いたコードでも処理速度を速くする方法はあるというのがひとつと、
Pythonで書くことによって簡単に書ける代わりに処理速度が犠牲になることが問題なのか考えるべきというのがもう一つある
処理時間よりコードが完成するまでの速さが大事な場合もあるからね

実際に本格的にプログラムを書くようになったら、楽さと速さとかその他の特性に合わせて適切な言語を選んで書くようになるので、
初めての言語なら気にしなくてよいと思う

2024/08/05(月) 23:06:08.80

困った時に考えればいいんだよ

2024/08/05(月) 23:14:29.13

Pythonそのものの話じゃねえだろw

2024/08/05(月) 23:47:18.26

Pythonは「コンパイルを必要とする他の言語に比べると遅い」は事実だけど、用途によってはそれでも十分という感じ
例えばちょっとした事務作業を簡略化するために「ファイルを読み取り、テキストの内容を適宜加工して出力する」くらいならPythonでも十分
それくらいなら0.1秒未満で終わるのが殆どだろうし、Pythonが遅いと体感することも無いと思う

それが数百、数千ファイルを処理したいとなると、いくらか「待たされる」感じにはなると思う
コンパイルされた言語での実装との差も感じられるはず
この待ち時間が十分許容できるなら問題はない

パフォーマンスが重要な分野はPythonは向かない
ゲームエンジンを1から作りたいという場面でPythonはありえないし、それで作ったゲームはとても重くなるはず

ただし、世の中には「他の言語で作られたPythonライブラリ」も多くあって、それを使う分には問題ない
例えば機械学習で使われるPyTorchはC++で書かれていて、それをPythonから扱えるようライブラリを提供している
だからPyTorchを使う分にはC++と同等の速度が出るけど、これもゲームエンジンと同じで、中身の部分はPythonで作れるようなものではない

2024/08/05(月) 23:58:29.54

中身のない長文はいいよ

2024/08/06(火) 00:10:59.10

初心者質問と書いてるんだから少しくらい丁寧に答えても良いと思うが
普段からプログラムを書くような人にとっては常識だけど、そもそもそういう人に向けたレスではないし

2024/08/06(火) 02:00:07.09

>>386
あんた素人すぎよ

2024/08/06(火) 02:01:28.55

>>386
ファイル操作なんてプログラミング言語のせいじゃない。

2024/08/06(火) 02:03:20.81

プログラム板はレベルが低いからなw

2024/08/06(火) 07:52:57.79

IOで遅くなってるのは何で書いても遅い

2024/08/06(火) 08:03:04.64

IOに限らないのだろ。>>386 は「ファイルを読み取り、テキストの内容を適宜加工して出力する」と言ったので。

2024/08/06(火) 10:24:07.35

イキったネットのフレンドωωω

2024/08/06(火) 10:35:02.43

Pythonはインタプリタの起動時間があるのでHello World出力するのでも0.1秒くらいは最低でもかかる
「ファイルを読み取り、テキストの内容を適宜加工して出力する」処理をほとんどの場合で0.1秒未満で終わらせるというのは無理

常駐プログラムにして起動時間を除いて考えるならファイルの内容や処理内容によっては可能かもしれない
ただ起動時間の遅さというのは常に付きまとうので5～10秒くらいは別に待っても構わないという処理でなければ違う選択肢を考えたほうがいいことが多い

2024/08/06(火) 12:19:06.97

>>395
？

2024/08/06(火) 12:23:27.81

>>395
？

2024/08/06(火) 12:44:03.72

>>395
それはほとんどOSとハードウェアの速度の話だぞ？

2024/08/06(火) 13:21:11.66

「pythonは遅い」
でよくね？

2024/08/06(火) 13:21:48.35

？

警備員[Lv.20] (ﾌﾞｰｲﾓ MM33-/5UW) · 2024/08/06(火) 13:33:03.34

？

2024/08/06(火) 13:41:58.05

？

2024/08/06(火) 18:27:06.81

>>398
> ほとんどOSとハードウェアの速度の話

でもいいんだ。
その条件を同一にした上での「他と体感的に感じるもんなん？」なのだろうから。

2024/08/06(火) 19:56:45.64

プログラムの起動時間なんて工夫がかなりしやすい部分だし、そういう部分まで持ち出してきて遅いから別のものを検討した方がいいとかいうのはFUDに近いものを感じるな。
そんなに起動時間気になるならカーネルモジュールでも書けばって気になる。
全体的に遅いのは覆せないとは思うけど、生産性の高さもまた覆せない特性で、無視できないことが多い部分だからね

2024/08/06(火) 21:08:40.59

>>399
Pythonは遅い
けれど仮に100倍遅くても問題ない分野は多いし、その範囲であればPythonの使いやすさというメリットが上回る
というのが妥当な評価だと思う

2024/08/06(火) 22:00:38.56

perlは部分的に異常に速い部分あるよな
正規表現とか
pythonはそういうのないな

2024/08/06(火) 22:18:08.13

そのへんが実感できるのは、事あるごとに時間測定してた人だけだろうな
perlで全ファイル読み込んで検索するより、
外部コマンドでgrepする方がよっぽど速くて悲しかった

2024/08/06(火) 23:24:30.52

アイアン‼マーイク。。。パイソン‼

2024/08/07(水) 00:03:12.33

>>407
事あるごとに時間測定なんてせんでも
ごく基本的なコスト意識で明白なケースだから題材が不適

2024/08/07(水) 00:06:07.93

>>407
なんでその条件でPerlの方が速いって思えるんだよ…

2024/08/07(水) 00:23:06.97

何1000回とgrepしたらキャッシュがあるとはいえ毎回ファイル読み込みが発生する
そんなことするよりオンメモリで検索した方が速い
perlはその有利さを台無しにするくらい遅かった

2024/08/07(水) 01:01:23.97

オンメモリってgrepもオンメモリでしょ…

2024/08/07(水) 09:19:05.25

結局、
「Pythonは簡単だけど処理速度が遅い」(質問者のネトゲのフレンド曰く)を、誰もが表現を替えて言うだけだな。

どの言語に対して処理速度が優位(或いは不利が少ない)であると >>370 は嬉しいのかを、俺としては知りたかった。

2024/08/07(水) 12:20:22.69

おまえらの話が高次元すぎてよくわからないが、スクレイピングやSQL操作やそれを元に計算する程度ならそこまでの体感差はなさそうってことやな？
このままPython学習頑張るぜ！！！

2024/08/07(水) 14:07:09.52

>>414
そういうことだ
頑張れ

2024/08/07(水) 14:25:32.05

pythonで目的を実現出来ていない人が、
速度を求めてより低級言語で実現できるとは思えないが。

2024/08/07(水) 14:54:42.48

ハードウェアに近いものを作るとか、速度が何に増しても重要だとか、そういうものでなければ、Pythonが第一候補になる
Pythonほどライブラリが充実してるものはないから

2024/08/07(水) 16:41:18.97

次の目標は、pythonのコードを多言語対応（英語と日本語）させて、Microsoft Storeで売るぞ
現在は他所で日本のみの販売、売上が5、6、7月と綺麗に7,000円ずつになってる（1本500円で販売）

2024/08/07(水) 17:11:17.36

>>406
numpy

2024/08/07(水) 17:12:50.73

>>416
ほんそれ

2024/08/07(水) 19:15:35.06

GUIもpythonでやり出して他の言語触ることが少なくなってきた

2024/08/07(水) 19:22:06.08

どういう用途にGUIを使うの?

2024/08/07(水) 19:23:15.39

なんぴー

2024/08/07(水) 20:10:49.00

>>421
環境依存だけどな

2024/08/07(水) 21:00:57.38

tkinter

2024/08/08(木) 01:18:29.98

パッケージソフトとして売るとかを考えなければ、Pythonが一番使いやすい
作りたいものを最も早く作れるのがPythonだと思う

2024/08/08(木) 06:39:11.73

？

警備員[Lv.21] (ﾌﾞｰｲﾓ MM95-/5UW) · 2024/08/08(木) 07:19:35.70

AUTO CAD 互換 CADを作ってクレメンス

2024/08/08(木) 07:49:05.69

普段使ってる大抵のソフトはpythonで作れない
動画再生ソフト、表計算ソフト、テキストエディタ、webブラウザ、
画像編集ツール、音楽編集ツール

2024/08/08(木) 08:31:55.19

作れないわけじゃないんだよなぁ
作っても遅くて使い物にならないから作らないだけで

2024/08/08(木) 08:43:03.90

この手の作業を自分の好きなように自動化させる事に向いている

警備員[Lv.22] (ﾌﾞｰｲﾓ MM95-/5UW) · 2024/08/08(木) 10:20:12.40

CVATを自動操作するツールを作ってクレメンス

2024/08/08(木) 13:37:28.10

>>426
自分の見える極狭い範囲のことだけなのに、全部がそうだと思い込む幼稚な頭の人かな

2024/08/08(木) 17:25:55.09

複数の変数初期化というか同じ値放り込みたいんだけど
a,b,c = (None for i in range(3))

なんかもっとスマートな方法ないのかな

2024/08/08(木) 17:30:52.14

レスした瞬間そっこー解決したわすまん
a=b=c=None

2024/08/08(木) 17:37:12.76

>>429
既にいいものが存在していて作る必要がない

2024/08/08(木) 18:32:36.69

以下を超える迂遠な方法を考案してくれたまえ、キミタチ。

>>434
> a,b,c = (None for i in range(3))

2024/08/09(金) 07:45:57.46

パフォーマンスを最適化するためのヒント

ループよりもリスト内包を使う
ジェネレータを活用して効率的な処理を行う
高価な関数呼び出しをキャッシュする
コンテキストマネージャでリソースを管理する
NumPyで演算をベクトル化

2024/08/09(金) 08:10:44.56

速度要ることが見えてるなら最初からpythonを選ばないのが正解

全探索でパズル解かせるとかやると、終わるまで何日もかかる
工夫で1桁くらい速くなるけど、結局Cに移植とかになる

2024/08/09(金) 10:18:56.99

>a=b=c=None
書き方の問題とは別に1つの関数内で3つの変数に明示的にNoneを代入する状況は避けたほうがいいように思う

2024/08/09(金) 16:44:08.25

それはNoneだからってこと？それともどんな値でも変数に同じ値入れる書き方を避けろってこと？　>>440

2024/08/09(金) 16:46:04.18

カレーが足りなくなるって意味ではないか？

2024/08/09(金) 16:51:15.37

C言語でNoneを表現したかったらどう書くんだろう

2024/08/09(金) 17:11:13.51

enum { None, Other }

2024/08/09(金) 22:09:09.69

初心者質問で申し訳ないんだが、仮想環境ってソフト作るときの保全のためだよね？
別に入門書とか勉強してる間は仮想環境でやらなくてもいいよね？

2024/08/09(金) 22:10:34.36

普通に実用で使ってるけど環境なんか作ってない

2024/08/09(金) 22:12:48.00

>>446
そうなんや
なんか入門書とかでライブラリとか入れたりして後から削除するとゴミが残ったりみたいな面倒なことがあるなら
仮想環境作った方が良いのか？って思ったけど気にしないで良いんやな

2024/08/09(金) 22:21:33.97

みんな最新にしてて問題が起きなければそれでok
複数のバージョンを切り替えないといけない事態が発生した時に考える

2024/08/09(金) 22:55:56.94

>>441
どちらかと言えばNoneだから
テストコードとかならあまり気にしない

2024/08/10(土) 04:21:40.95

階層上のpythonファイルをimportするとき相対パスの方が圧倒的に可読性高いと思うけど
頑なに絶対パスで書こうとする人ってなんなの

2024/08/10(土) 08:10:56.63

絶対に同じ環境でしか使わないぞと言う鋼の意思表示

2024/08/10(土) 08:22:50.16

FSのパスじゃなくてsys.pathからのパスじゃないの？
それならトップから書いてても言うほど変ではない
どこまで階層掘ってるのかしらんけど

2024/08/10(土) 14:33:30.87

相対パスで通らなかったからだよ

2024/08/10(土) 14:40:10.17

動いてたものが、ちょっと起動の方法を変えたら動かなくなったりする
相対パスとかカレントから読むとかはやらないのが吉

2024/08/10(土) 16:20:46.44

環境変えたら動かなくなる、ってそれ相対やらは関係ないのでは

2024/08/10(土) 16:25:51.39

>>449
どちらかと言えばのニュアンスがちょっとわからないんだが
def hoge(a=None,b=None,c=None)
もやめといた方がいいってことかな

2024/08/10(土) 17:04:28.50

変数を初期化する、というアイディアがあんまり無いんだろうな
何かを入れる為に変数を用意するんだから、入れる前の値なんかどうでもいい

2024/08/10(土) 17:20:32.64

最適化にはつながらないけれど
複雑化が進むから変数はなるべく再代入したくないな

2024/08/10(土) 17:28:23.63

予め何か入れておいて、判定なりループを抜けて、
一度も値が変更されなかった印として元の値が残ってる

というアルゴリズムは、自然ではあるし、読みにくくもないし、
昔からある定番のものだけど、バグの元なんだよな

必ず何かが入るようにして、もし漏れてたら参照時にエラーになる
という作りにした方が安全

2024/08/10(土) 18:26:13.49

なんとなくyoutubeとか見ながらエディタはVScodeにしたけど
Pythonメインで使うなら後々パイチャームが良いみたいな感じになったりする？
どっちも使ったことある人おすえて

**デフォルトの名無しさん** (ｽﾌｯ Sd33-QylA) · 2024/08/10(土) 23:55:03.51

どっちでもいい

2024/08/11(日) 10:42:41.95

そ、そんな……

2024/08/11(日) 11:22:20.74

>>456
それは別にいいと思うよ
避けたほうがいいと思うのは
def hoge(arg):
　a = b = c = None
　…
　return a, b, c
とか
def hoge(arg):
　a = b = c = None
　…
　return fuga
とか

2024/08/11(日) 12:04:42.70

C言語の頃の因習だよな
auto変数を宣言してもスタックからアドレスが確保されるだけで、
何が入ってるかは判らないので、必ず最初に初期化しましょうという文化が出来た

面倒なので、perlとかは初期化せずに参照しても初期化済ということになった

そんな手抜きをするとやっぱりバグるので、
未定義という状態を追加して、参照したらエラーが出るようにした

言語仕様が許してくれるからより安全な方法が使えるというだけで、
C言語に戻れば初期化しないなんて言語道断

2024/08/11(日) 15:26:51.19

>>463
つまり
>>449 ＞どちらかと言えばNoneだから
ってことは
def hoge(arg):
a=b=c=0

とかなら別にってこと？？

2024/08/11(日) 15:51:01.99

2段落目3段落目のperlのundef話は違うような

2024/08/11(日) 16:06:10.84

その関数内で使う変数は全て、関数内の最初に宣言
ってのは違うと思うけど
重要なやつくらいは良いのでは・・？

2024/08/11(日) 16:50:21.66

> そんな手抜きをするとやっぱりバグるので、
> 未定義という状態を追加して、参照したらエラーが出るようにした

全く違う言語でだけど
初期化をすると、このエラーを抑制してしまうため
未初期化を意味するような無駄な初期化は止めるような流れになった、とか

2024/08/11(日) 17:15:29.30

デフォルト引数も初期化宣言みたいなもんじゃないの？
関数アノテーションに組み込みでバリデーション機能がないわけで
宣言は仕方なくね

2024/08/11(日) 18:47:02.80

>>465
そうだよ