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/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から書き込まなあかんねん

2024/08/23(金) 21:29:56.30

>>696
勝手にau Wi-Fiに繋がっているだけ

2024/08/23(金) 21:35:38.93

自動で繋がるのは当たり前の機能で、繋がる環境に君が今いるということだろう
他にすることないんか
家に帰るとか

2024/08/23(金) 22:14:23.89

引きこもりなのか？

2024/08/23(金) 22:15:06.39

自宅のPCで5ちゃんねるというのもめずらしいよ。

2024/08/23(金) 22:19:32.31

つくづく裾野が広い
駅のホームで電車来てるのに動こうともせずにスマホ凝視してるゴミみたいな層が、
実はpythonに興味あったりするのか

2024/08/23(金) 23:10:24.13

>>701
このスレッドはそんな層が見ている

2024/08/24(土) 14:46:48.38

無駄なコメントだらけのソースの方が読む気無くすから
保守には不向き

2024/08/24(土) 15:11:35.07

無駄なコメントは残すくせにドクストリングをろくに書かないやつはダメだ

2024/08/24(土) 16:26:43.77

コメントやアノテーションから自動でドキュメント作ってくれたり
GitHub Copilotがもっと進化したらそれすらいらなくなるんだろうな

2024/08/24(土) 16:35:31.39

ドキュメントはコメントで自由なフォーマットで書いた方が書きやすいし読みやすい

2024/08/24(土) 16:48:38.21

自由ってのもどうなんだろうな
「もう一つのシステムがある」という名言を残したあるAIは自由とはまぼろしである、自由などないと言ってるが

2024/08/24(土) 19:58:26.40

VBAで数本プログラムをした経験です
Pythonの学習にトイプロという無料学習ツールが有りますが、これはおすすめですか？

2024/08/24(土) 20:09:13.96

はい

2024/08/24(土) 20:10:36.75

いつのまにかseleniumにheadless=newというオプションができてた
headlessにするとまともに動かなかったツール類がこれだとちゃんと動く
そもそも動かないのがおかしいんだけど

2024/08/24(土) 20:12:53.79

イマニューから
@abhishekkrthakur
見とけばええんちゃう

2024/08/24(土) 20:35:15.84

>>707
セカンドライフか

2024/08/24(土) 22:43:33.25

ITエンジニアの人いる？
Pythonって何に使われてるの？
AI以外で。

バックエンドってとこ？

2024/08/25(日) 00:10:32.73

用途の多い言語だし一概に言えるものじゃないと思う
その質問をして、ここで出た回答だけを見て「Pythonはこういう用途」と言えるものでもないかと

2024/08/25(日) 00:12:58.35

PC用アプリ作ってるけどフロントにpython のapi を出してる

2024/08/25(日) 00:46:01.00

>>715
そうなんだ

webじゃなくWindows用ソフトってこと？

2024/08/25(日) 04:20:36.13

アプリならDropboxとか
Unix系OSの管理スクリプトもPython多い
クラウド開発基盤のSDKはまずJS/Python用が提供されるイメージ

2024/08/25(日) 07:08:32.01

>>709
ありがとうございます
トイプロの形態だと、段階的に習得できそうです。

2024/08/25(日) 08:18:55.02

TOYPROみたいな難易度だと馬鹿にされてる気にならないか
AtCoderの過去問のギリギリ解けないくらいの難易度に挑戦するのがいい

**713** (ﾜｯﾁｮｲ 0202-wgTk) · 2024/08/25(日) 12:06:13.04

>>717
ふむ

わりとバックエンド系が多い感じかな？
AIしか作ったことないから、よくわからないわ。

最近は、JavaScriptを勉強し始めたわ

2024/08/25(日) 16:43:39.90

Pythonは少なくとも国内ではバックエンドというかバッチ処理が多い
COBOL→Java→の流れでSIerのゴミが大量に流入してきている

**713** (ﾜｯﾁｮｲ 0202-wgTk) · 2024/08/25(日) 17:01:03.91

>>721
ふむ

昔つくったCOBOLを、Pythonで作り直すって感じ？
需要は多いのかな？

2024/08/25(日) 19:14:35.71

COBOLは十進法をきちんと扱えるという以外にはほとんどメリットがない言語という印象しかない

2024/08/25(日) 20:04:56.14

大昔の言語なのに自然言語みたいに書こうと思っただけで凄い