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/18(日) 14:50:10.51

>>555
つまらん探偵ごっこなんてしてる暇があるなら
PyObjectのソース観ろ
それで終了するから

2024/08/18(日) 14:51:51.47

>>558
ほんそれ

2024/08/18(日) 15:05:37.22

>>596
いくらでもあるでしょ

2024/08/18(日) 15:08:54.32

変更して元の行列と比較とか普通にあるぞ

2024/08/18(日) 15:16:22.68

>>596
木構造とかグラフ構造丸ごとコピーしたことあらず？
差分計算とかそれなりのアルゴリズム書いてたらいくらでも起きるよ

2024/08/18(日) 15:17:02.64

>>596
519だが、
ほんと、
バカレスしか返ってこないよね…

2024/08/18(日) 15:18:16.40

>>602
あ、
でもTransformerを作ったときにあったかな…

2024/08/18(日) 15:22:26.84

>>602
おーいバカしか言ってねえぞw
バカはどっちだ？

2024/08/18(日) 15:23:47.91

>>603
おーい自演失敗してるぞ

2024/08/21(水) 01:13:03.16

初心者質問で申し訳ないんだが
文字列はシングルクオートとダブルクオートどっちでやってる？？？

2024/08/21(水) 07:54:08.92

r'"C:\Program Files\dotnet\dotnet.exe"'
みたいなことしたいしな
等価といいつつ、よそのシステムで'が使えないなら、python側で使っとくのがお得

2024/08/21(水) 10:34:49.22

フォーマット文字列使うときとかは
a='"A"'
b='"B"'
t1 = f'"{a}" & "{b}"'
t2 = f"\"{a}\" & \"{b}\""

大抵２，３段ネストまでなら耐えられるし、そんなに使わないので
基本シングル使ってる

2024/08/21(水) 13:32:05.73

必ず """"6重引用符(triple double quotes)"""" て猛者はいないのか。

2024/08/21(水) 14:54:06.77

今自作言語のパーサーをPythonで試作してるけど
IDEにレポートできる形式で
複数行にまたがるトークンのパースの面倒さを体験してるから
トリプルクォートは使用をためらう

2024/08/21(水) 15:00:04.91

関数内で引用符使うとき関数分のインデント水増しされるのすげえモヤモヤするよな

2024/08/21(水) 15:26:37.08

IDEのエディタが最小限の状態管理しかしないから
基本インデント維持で行末がコロンならインデント増やすっていう
簡素なシステムが多い

2024/08/21(水) 19:35:23.85

perlで'がそのまま"だと変数の内容が展開される
という仕様だったので、基本は'だった
pythonにf文字列が追加されてからはどうでもよくなった
black通すと"にされる

2024/08/21(水) 20:00:58.88

そういえば、エスケープのためのバックスラッシュも複数重ねることが必要なことがあるけど
シェルスクリプトでsedを使うといい加減にしてくれっていうくらい必要になって流石に嫌になった
pythonのraw文字列はほんと助かる

2024/08/21(水) 20:14:00.79

rawはwindowsのパスを書く時にバックスラッシュをそのまま書きたくて使うことが多いけど、
バックスラッシュで終わるパスがrawでも書けないっていう

2024/08/21(水) 21:08:18.62

>>613
perlのやつ非常にわかりやすい

2024/08/21(水) 21:15:04.72

その代わり、全部の変数に$付けないといけないけどな
あの$まみれコードはやっぱり見苦しい

2024/08/21(水) 22:02:22.40

>>606
他のプログラミング言語ではダブルクォーテーションが普通なのでダブルクォートが無難。

シェルスクリプトだとシングルクォーテーションが普通だが、ダブルクォーテーションでくくると文字列という解釈になる言語が多い。

日本語でも英語でもダブルクォーテーションが言葉の括弧書きになる。

シングルクォーテーションは文字列ではなく、文字を表すときに使う言語があるので、高水準言語では文字列はダブルクォーテーションをくくるのが常識レベル。

2024/08/21(水) 22:04:21.99

ネット記事に頼るのではなく、古いものを含めていろんな書籍でどう書かれているのか見比べることが重要。

2024/08/21(水) 22:10:45.48

>>606
初心者でどっちがいいかわからないならダブルクオートがおすすめ
pythonやJSでは違いがないとか、C系言語では違いがあるとかわかってきたならシングルクオートかな

2024/08/21(水) 22:15:19.66

Excel VBAも知らねえのか？

2024/08/21(水) 22:17:54.09

確かに
ダブルクォーテーションが好きなのは低所得者層、シングル使ってるのは上の層って感じ

2024/08/21(水) 22:21:32.21

C/C++開発者は低所得
たしかにビジネス感覚がズレてはいそう

2024/08/21(水) 22:40:00.03

ruffでフォーマットするとデフォルトでダブルクォーテーションになるから自分はそちらに統一してる
モダンなツールがそちらをデフォルトとしてるんだし、シングルに拘る必要もないと最近思い始めた
(もちろんツールの設定でシングルにもできるので、そちらが好みの人はそちらでも良い)

2024/08/21(水) 22:41:14.56

Pythonが作られた時代はダブルクォーテーションとシングルクォーテーションの混在時期だが、ダブルクォーテーションを積極的に使ったのはマイクロソフト社。

混在が混乱を招くという発想でシングルクォーテーションに統一した言語はもっと前からあるが。

2024/08/21(水) 22:41:53.27

>>624
意味が変わることがあるのを知っているのか？

2024/08/21(水) 22:47:54.59

Libにあるいろんな他人のコード見てると、'が多数派なんだよな
print用の文字列は"で、引数は'だったり
謎の使い分けがある気がする

2024/08/21(水) 22:51:37.29

こういうのはまずPEP8を見ないといけない(どっちでもよいと書いてあるけど)

String Quotes
In Python, single-quoted strings and double-quoted strings are the same. This PEP does not make a recommendation for this. Pick a rule and stick to it. When a string contains single or double quote characters, however, use the other one to avoid backslashes in the string. It improves readability.

For triple-quoted strings, always use double quote characters to be consistent with the docstring convention in PEP 257.

2024/08/21(水) 23:04:44.31

日本語キーボードだとどっちもShift必要だけど、英語キーボードならシングルクォートは1キーで済むしな

2024/08/21(水) 23:05:37.93

文字列にシングルクォートかダブルクォートはでシングルクォートどっち使うか
これ結構色んなとこで聞いたことあるんだけど、シングルの方が書きやすいだった
英語配列のキーボード使い始めたらその理由実感できた

**630** (ﾜｯﾁｮｲ 9fa9-9uNt) · 2024/08/21(水) 23:09:25.20

>文字列にシングルクォートかダブルクォートはでシングルクォートどっち使うか
文字列にシングルクォートかダブルクォートどっち使うか
すいません、ちょっとバグってました

2024/08/21(水) 23:21:36.60

全角のダブルクォーテーションマークは開きと閉じでコードが違う
“”(201C, 201D)
〝〟(301D, 301F)
〝〞(301D, 301E)

2024/08/21(水) 23:31:15.57

>>626
文字列中にダブルクォーテーションを使う場合はシングルを使う、といった話なら分かってる
あと DocString はダブルが一般的
それ以外の通常の文字列だとシングルとダブルに違いは無いよね？

2024/08/21(水) 23:34:50.10

docstringはトリプルじゃないの
逆にそこくらいしか使わない

2024/08/21(水) 23:42:23.11

実際にはdocstringを丁寧に書くこともなくて、docopt用なんだけど

2024/08/21(水) 23:44:03.07

コピロットとかじえみにのプログラムコードエラー吐きすぎ

2024/08/22(木) 00:00:06.37

>>634
基本的にはダブルクォート3つでありシングル3つは使わない、という意図で書いた
例えばDocStrgngを生成するVS Codeの拡張機能なんかでも、ダブル3つは反応するけどシングル3つは反応しない
文字列値はシングルとダブルどちらでも良いけど、DocStigngは明確にダブルの方が良いと思う

2024/08/22(木) 00:16:00.81

mac/win問題あるよな
コーテーション

2024/08/22(木) 00:17:08.85

ダブルコーテーションの文字"の高さが揃ってるからダメなんじゃないって思う
ちょっと上下にずらして欲しい

2024/08/22(木) 01:06:26.79

>>628
それは最初に作ったときの仕様がそうだからだ。他のスクリプト言語の影響を受けている。

自由に使うのはかまわないが、コーティングにルールがないのはダメなプログラマー。

2024/08/22(木) 01:22:57.56

>>633
SQLの世界ではシングルクォーテーションだから、SQL文字列を作成しようとするとシングルクォーテーションはすぐに面倒なことになる。

しつこすぎだが、高水準言語はダブルクォートテーションでほぼ統一されている。
SQLではシングルクォーテーションで統一されている。

シェルスクリプトでは意味が変わることがあって同じではない。

Pythonが出来損ないのプログラミング言語とわかっていないようだが、どちらでもよいというのは統一できなかった歴史があるからだ。

Pythonはシェルスクリプトと似た使い分けがある。
UNIX・Linuxの世界ではシングルクォーテーションはくくった中身の展開する、ダブルクォートテーションは中身を展開しないというルールがなんとなくあり、外部のプログラミング言語やライブラリがバラバラであるためにPythonもフラフラしているだけ。

見ているサンプルがどっちつかずなのは、どっちつかずの悪いサンプルにすぎない。
プロはどっちつかずのコーティング規約など作らない。

Pythonは全体的にコーティング規約を作らないとバラバラになるクソ言語。

2024/08/22(木) 01:24:59.98

初心者スレならともかく、Pythonの言語仕様がよくないと気づかないようであれば、他の高水準言語を先にやった方がいい。

2024/08/22(木) 01:25:42.34

PythonはPerlと同じクソの道を進んだクソ

2024/08/22(木) 01:31:52.11

Pythonでは変数名をアンダーバー区切りで命名するように推奨しているが、無視しているやつも多いしな。
他のプログラミング言語の慣習を持ち込むやつは必ずいるからコントロールが難しい。

2024/08/22(木) 08:40:19.40

Pythonでは伝統的に名前をあまり長くしないでlowercaseみたいに区切らないのが基本で、
アンダースコアで区切るのはどうしても長い名前を付けたい場合の次善の策
最近はアンスコ多用が顕著だけど、あれも本来は他所から持ち込まれた慣習なんだよ

2024/08/22(木) 09:00:26.31

>>645
あんた高齢者だろ？

2024/08/22(木) 09:02:44.58

短い名称にする理由は、昔は名前が長いだけでデータが大きくなるという理由から避けていた。

いまは短くしてテキストデータを小さくするメリットは皆無。

2024/08/22(木) 09:22:20.02

タイプが楽でしょ
エディタの補完があるとはいえ、Jupyterなんかだとあまり品質良くないし純粋な静的型やJSに比べたら自分でタイプする機会は多い

2024/08/22(木) 09:34:43.72

会話だと自然と短く言い換えてるのに
コードだと冗長な修飾しがちなひと多くて不思議

2024/08/22(木) 09:42:47.77

最近では生成AIが比較的長い名前を生成しがちだったり、
長い名前の方が生成AIに対して与える情報量が増えてコード生成の精度が向上するという面もあるだろうね

2024/08/22(木) 11:05:20.13

>>622
めっちゃ判りますωωω
Rustのlifetimeの'は糞

2024/08/22(木) 11:10:51.19

>>641
シェルスクリプトに限らず
tcl/tkとかRubyωとか使うと良く判る

2024/08/22(木) 11:24:35.95

書籍に書かれているサンプルがプロのコード例だと初心者は思い込むからね

2024/08/22(木) 12:53:25.45

name_listとかname_dictみたいな命名は悪

2024/08/22(木) 13:07:40.15

変数名をタイプするのは命名する時だけで、その後は全部コピペだけどな

2024/08/22(木) 13:29:25.29

>>618
ありがと
まだPythonしかやってない初心者ならダブルクォーテーションでいいんだね
ダブルクォーテーションでいきます！

2024/08/22(木) 14:35:19.45

>>654
コンテキスト無しに一律悪と決めつけないほうがいいよ

2024/08/22(木) 14:39:47.77

perlだと$nameと@nameと%nameが同時に使えたのにな
pythonに移植する時は、name_listとかにする

2024/08/22(木) 17:12:40.56

>>654
それ英語だと語順が逆だぞ？　

2024/08/22(木) 17:15:37.00

ネット上のサンプルだと省略しすぎの名前で何の変数なのかわからない。

しかもPythonは実引数と同じ名前の関数内のローカル変数が使えるなど意味のわからない仕様になっている出来損ない。

2024/08/22(木) 17:21:54.56

name listという英語はある
この場合は、型名を追加しているので語順も何もない

2024/08/22(木) 17:24:07.85

ハンガリアン記法かよw
それだったら、逆だろw

2024/08/22(木) 17:39:31.91

逆に書きたいなら好きにすればいい

2024/08/22(木) 18:27:02.99

>>659
list_of_nameは長い
ただのリスト変数にアンダースコア二つは長い
そもそも型表記するような時点で問題なのでname_listもダウト
namesがアンダースコアなくてよい

2024/08/22(木) 18:32:55.35

辞書型の names とどう同居させるのよ。

2024/08/22(木) 18:45:32.81

それもっと説明的な名前が必要なパターン

2024/08/22(木) 18:46:11.96

dataの場合はdatasな

2024/08/22(木) 19:10:59.48

is_*
has_*
くらいは使っていいんだろ？

2024/08/22(木) 19:14:12.53

リストは複数形という規則で命名
辞書はname2ageみたいな規則が普通か

2024/08/22(木) 20:07:24.13

単純に本人は日本語の語順にこだわりがあるようだ

2024/08/22(木) 20:30:08.48

単語の切れ目の最初の文字を大文字にする派

2024/08/22(木) 20:35:33.25

もうなんなん君らw
カオスやなw

2024/08/22(木) 21:02:28.42

キャメルケースみたいなのを使いだしたのが少しあとのマイクロソフトだから、Pythonは何もかも過渡期みたいな状態でできている。

こんなポンコツを初めにやらされるのもつらいよなあ。
いろんな本でもPythonの変な説明と変な用語と変な仕様のせいで、プログラミングそのものに集中できない。

2024/08/22(木) 21:07:49.26

キャメルケースは商標用だろう
一般人はアンダースコアとか知らん

単語の区切り文字としてトークンを分割しない何かが欲しい
となったら、アンダースコアを27文字目のアルファベットとして使うことに昔から決まってる
最も合理的で読みやすい
他の言語にも積極的にお勧めしたい

2024/08/22(木) 21:28:07.83

Pythonで大文字は定数とかクラスだよね
大文字入ってる時点で普通の変数でないとひと目で分かるのは便利よ

2024/08/22(木) 22:11:01.12

>>659
そんな語学力で大丈夫か？
中1英語からやり直したほうがいいぞ

2024/08/22(木) 22:41:09.45

>>676
彼はハンガリアン記法のような種別を後ろにつけていると主張しているんだぜ？

2024/08/22(木) 22:47:53.56

要素が1つならそのまま入ってるし、
複数ならリストが入ってる
みたいな仕様あるけど、型は固定の方が座りがいいけどな

言語仕様としては型は動的だけど、静的に使うのが吉
型情報を変数名に盛り込むのは理解の助けになりこそすれ、何もデメリットは無い

2024/08/22(木) 22:49:27.40

シェルスクリプトの変数は全部アンスコつける

2024/08/22(木) 23:03:25.22

コンピュータからすると評価時に区別できればいいから
どう命名しようがどうでもいいけど
人間は文脈で理解をすすめるので冗長な命名されるとなぜか理解が落ちる
専門外なのでわからんけどキャッチボールできてない気持ち悪さを感じるというか

2024/08/22(木) 23:44:13.46

list/lst、dict/dic、set
アンダスコアつけて、頭につけようが、ケツにつけようが、
普通に見てわかりゃいいんじゃないの？

ハンガリアン記法をするつもりじゃないから、
自分はあくまで名前が先で、種別は後付のほうがわかりやすいし、すんなり入ってくる

2024/08/23(金) 18:10:17.63

>>681
日本語のコメントをちゃんと書く習慣がないと変数名を短くしたがる

2024/08/23(金) 18:10:58.59

秋葉原のカフェでコードを書いているやつの画面を見るとノーコメントのコードを書いているやつばかり

2024/08/23(金) 18:15:07.60

ちゃんと書けば基本コメント不要

ここは後で読んだ時に判らなくなるかも、という部分にコメントを書くけど、
判らなくなる書き方をするのが悪い

2024/08/23(金) 18:22:29.48

>>684
それは経験不足だぜ？
他人が見てわかるか、1年後の自分が見てもわかるかどうかは重要。

こうした理由を書かないと将来、面倒なことになる。

コメントを書かないとクソ設計になりやすいし、自分にすべてを任せてくれなくなる。

2024/08/23(金) 18:23:18.76

>>684
「判る」は「分かる」か「わかる」だ。
国が決めた漢字の使い方すら無視した我流だなw

2024/08/23(金) 18:42:11.10

>>686
「判る」は「物事がそれと判別・判断される」（『明鏡国語辞典第二版』大修館書店）という意味であり、「判明」「判別」といった漢語が連想されます。例えば、「倹約と吝嗇りんしょく（注）の違いが判らぬ」「敵方の人間なのか味方なのか判らなかった」などと用いられます。

2024/08/23(金) 18:50:55.75

#ここでは判断するという意味を持つ
わかる

と書くのがコメント主義

判る

と書けばコメントなしで判断するという意味のわかるということが判る
後者であるべきなのだ

2024/08/23(金) 18:59:52.67

裾野の広さを感じる

2024/08/23(金) 19:33:03.79

どんな状況でもコメントが必要だとも思わないが、
コメント不要になるように書かれていないコードは不正解とも思えない
方程式から求解するコードとか実装の事情に依存せざるを得ないことが多いし、そういうのは十分にコメントを書くかなあ

2024/08/23(金) 20:17:32.58

何回か書いてたら
#いらんやろ

2024/08/23(金) 20:25:35.39

バグがないならコメントは不要
コーディングミスを分析するためにどのような意図であったかを確認する必要がある

2024/08/23(金) 20:28:47.91

そういうのはテストを書く

2024/08/23(金) 20:41:02.19

>>687
漢字の使用は自由だが、政府、文部科学省、マスコミ、国語の機関等で使用に関することを決めている。

辞書を引いたなら「△」という記号がついているから、それは常用漢字の表外音訓というあまり勧められない漢字の使用方法ということだ。

2024/08/23(金) 20:42:22.58

もともとコメントがいらないレベルまでモジュールを分割しろという話が、コメントがいらないという話だも誤解しているだけ

2024/08/23(金) 20:44:32.16

なんでそんなことを今、公衆Wi-Fiから書き込まなあかんねん