Pythonのお勉強 Part71

2023/09/20(水) 09:13:41.41

↑スレ立てる毎に減るので、減ってたら３つに補充すること。

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

★Pythonのソースコードを５ちゃんに直貼はインデントが崩壊するので、
　　↓等のコードうｐ用サイトに貼ってきてくだしあ。（スクリーンショットをうｐる「横着」禁止）
ttps://techiedelight.com/compiler/　　Run Code機能あり。
ttp://ideone.com/　　　　　　デフォ設定がCなので、Pythonするには言語種選択ボタン押下がﾋﾟｺ手間かも。
ttp://pastebin.com/　　　　　まずまずシンプル。
ttp://dpaste.com/　　　　　　とてもシンプル。消えるまでの日数は十分長ーく指定のこと。

◇Pythonオフィシャルサイト　http://www.python.org/
◇Pythonドキュメント　https://docs.python.org/ja/3/
◇まとめwiki　ttp://python.rdy.jp/
※前スレ
Pythonのお勉強 Part70
https://mevius.5ch.net/test/read.cgi/tech/1677856680/

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

2023/09/24(日) 11:05:04.02

Cでは今でも書いてるけど、C++は書いたことないな
拡張子だけcppで複素数とか使ってるけどクラスは使ってない、程度なら書いた

2023/09/24(日) 13:17:50.18

python使いたくないんだけどpythonにしかないライブラリを再発明するパワーもないので仕方なく使っている

2023/09/24(日) 13:23:16.93

こんなソフト無いかなと検索しても、windows用が無くてandroid用しか見つからないようなもんか

2023/09/24(日) 13:29:34.13

>>103
pythonでQt触っててC++でも触ってみたらC++も良くなっててこっちでもいいやんって思ったけど
ライブラリ探したりコンパイルするの面倒くさく感じてやめた

2023/09/24(日) 13:42:18.77

>>105
Nim使えばいい

2023/09/24(日) 14:31:18.01

C++はソフトウェアに最小限必要な制約の記述と
最適化に関する記述を分離できていない
全部ごっちゃ
その意味ではRustも大差ない

2023/09/24(日) 15:03:52.20

>>108
pythonのライブラリ使えるのか？

**デフォルトの名無しさん** (ｽﾌｯ Sdaa-TrDt) · 2023/09/24(日) 15:21:16.70

馬鹿には無理

2023/09/24(日) 15:34:59.57

>>107
Python/Qt 最高だよね。
もう、ヘッダーファイルを書くなんて面倒で面倒でw

2023/09/24(日) 15:44:30.62

Qtが企業だと知って萎えた
無料で仕事してくれる人なんていないよね

2023/09/24(日) 17:14:53.18

>>108
Nim使うからRust使うわ

2023/09/25(月) 08:05:09.08

>>97
型宣言付けたら自動補完きくからコード書きやすいだろ
バグ取りも圧倒的に楽だし
他人のコード読むなら絶対あったほうが楽
見た目が醜いのはそうだけど静的型チェックなんだから自分しか使わないならいらないと感じたとこで消せばいい

Pythonはカッコ少ないのは美点だと思うけどじゃあprintもカッコなくして文に戻してよって思う

2023/09/25(月) 08:08:58.57

型チェックを憎むやつの正体
・IDE嫌いの老害
・メソッド名や属性名を全て覚えておりどの変数に何が入っているか全て知っている天才
・簡単で汎用性の極めて乏しいスクリプトしか書かない人
・numpyなどで実質型指定の恩恵を受けている

2023/09/25(月) 08:47:06.87

>>115
静的型チェックではないぞ

2023/09/25(月) 09:07:43.95

文字か数かは見れば判るし、
リストとか辞書の場合は、変数名をそうしておかないと型チェック以前に書くのに困る
なんちゃってハンガリアンで十分

現状困ってないのに型チェックを導入するのは、理不尽なコーディング規約みたいなもので、
慎重になった方がいい

2023/09/25(月) 09:45:41.16

>>117
型付けが動的なだけで型チェックは静的

2023/09/25(月) 09:52:10.17

型付けの静的/動的とチェックの静的/動的は意味が違う

2023/09/25(月) 10:44:27.45

現状困ってなくてもエディタの入力補完の恩恵を受けられるようになるのは大きなメリットだと思うけどな

2023/09/25(月) 11:19:52.99

>>118
強制されてないんだから恩恵がない天才派はそれでOK
じぶんは名前に型含んでたらレビューで難癖つけるけどね

2023/09/25(月) 11:33:59.63

for data in data_list:
とかよく書くけどな

複数形を使うのはあんまりいい方法と思えない

2023/09/25(月) 12:04:10.57

x_intとかx_strみたいな変数名のことじゃなくて？
型アノテーションなかった頃は見てわかる変数名はいいアイディアだったと思うけど今はアノテーション使って書くな

data_listみたいな名付けはする
datas, xsは最悪だと思うけどx_listだと長過ぎるように感じて悩んでる
この辺ってルールあるの？

2023/09/25(月) 12:38:00.66

datumの複数形がdata
もしくは不可算名詞の単数形としてのdata
datasは間違い

2023/09/25(月) 12:47:41.75

リストは複数形、というルールにしたとしても、辞書はどうするんだっていう
名前に型含めると噛みつくうざい人がいたとしても、含めた方がいい

2023/09/25(月) 12:56:23.29

オナーニばかりしてんちゃうぞ
pep8の通りにやることめざしゃ

2023/09/25(月) 12:59:59.83

それ良く言われるけど
英文法の例外に合わせる必要なんてない
hogeがあったら機械的にhogesにする
Railsでも採用されてるnameイングルール

2023/09/25(月) 13:00:41.69

>>116
> 型チェックを憎むやつの正体
> ・IDE嫌いの老害

「型」を寧ろ老害扱いしてたんじゃ。

2023/09/25(月) 13:01:12.12

datasをdata_seriesの略だとする言い訳もある

2023/09/25(月) 13:01:37.98

型の判別のためではなく、それが何かを表すために変数名にdicを含めることは普通にあるだろう
結果として型名が含まれてるだけであってそれをレビューで弾く必要はなかろう

2023/09/25(月) 13:05:46.35

ほんとに辞書ならdictでいいよ
request_header_dict
は止めてほしい

2023/09/25(月) 13:41:51.05

意味、役割が辞書的なものなら実際の型によらずdictでも別にいいと思うけどな

2023/09/25(月) 13:49:27.17

perlは楽だった
$dataと@dataと%dataが同時に使えて、
リストなのか辞書なのか見ただけで判るし名前で苦労しない

2023/09/25(月) 14:10:52.93

>>134
ハンガリアン記法で代替すりゃいいじゃない。

2023/09/25(月) 14:18:03.40

まあ、@dataとdata_list、%dataとdata_dictが同じものなので、
記号で書くか文字列で書くかの違いだけなんだけど

実際、perlから移植する時はそんなふうに機械的に置き換えてる

2023/09/25(月) 19:20:02.88

>>118
>文字か数かは見れば判るし、
それが通用する程度のプロジェクトなら必要性を感じられなくてもしょうがない

2023/09/25(月) 19:33:05.13

規模が大きくなると訳が判らなくなっても仕方ない
という諦めに抗い続けたのが言語の進化の歴史なんよ

2023/09/25(月) 19:38:40.05

処理系は処理系で必死に変数の型をなくそうと努力し、
利用する側は利用する側で変数の型を意識しやすくしようと努力する

2023/09/25(月) 20:02:55.68

一部の人が苦しい思いをしながら型を意識して書いたライブラリを、
大半の人は型なんか意識せずに気軽に使う、という分業が今のところの正解なのだろう
一つの言語だけで全体をカバーするのは無理

2023/09/25(月) 20:19:47.64

>>140
「見ればわかる」程度のコードしか書かない人にとってはそうかもしれないが
そんなんばっかりなわけはないからな

2023/09/25(月) 20:28:32.03

見れば判るコードが一番いいコードなんだよ
なんで難解さをドヤれるんだ

2023/09/25(月) 20:33:17.65

伸びてるな

>>142
そういう意味じゃないでしょうｗ

2023/09/25(月) 20:34:55.62

>>142
単純に規模が大きくなるだけでも「見ればわかるとは言えなくなるだろうに。
それともお前の頭じゃ関数定義するだけで難解なコードなのか。

2023/09/25(月) 20:35:22.38

フェレイゼンも30年の研究の結果
プログラミングには型が必要だとわかったといってた

2023/09/25(月) 20:39:42.84

小さいプログラムしか書かない人は型が要らないと言う
別に書くことを強制されてるわけでもないのに

小さくてもファイル3個ぐらいに別れてたら絶対型がいる

2023/09/25(月) 20:43:06.80

設計書ないの?

2023/09/25(月) 20:45:48.37

自己満オナニー主義者としてはやはりPEP8くらいマスターしておきたいよなー
自分で読んでわかるのも2・3年後に読んだらわからんくなる人もいるし
いつも同じオナニーばっかりの人はどっちよりに曲がっていても気付かないものだしな

2023/09/25(月) 20:47:01.71

Pythonを研究で使う人って設計書書かないっしょ
あとから必要になったときにリファクタリングするついでに設計書書く感じじゃね

2023/09/25(月) 20:48:13.53

なんだか見てると頭が痛くなるな
py界はちょっと参加者が違う

2023/09/25(月) 20:49:47.51

>>138
その言語の進化の歴史に型ヒント、型チェックは含まれるの？

2023/09/25(月) 20:50:39.88

なんで研究前提になっているかは知らんが、
システム・ライフ・サイクルがある程度の期間であれば設計書は作成するでしょ。
記憶できない規模なら、なおさら。

2023/09/25(月) 20:58:58.46

趣味のプログラムならそんなものは作ってないだろう
最初はモジュール含めてトータル3000行だったものが1万行オーバーとか普通だし

2023/09/25(月) 21:07:13.67

#データ読み込み
#加工
#ライブラリに渡す
#結果をプロット

しかやってない人は型はいらないというだろうけどこれでも型はいると思う

2023/09/25(月) 21:35:08.48

本当に必要なのはデータを取り違えない適切なアノテーション
型自体は最適化の領分

2023/09/25(月) 21:44:51.84

実現したいことが30行程度の人はある意味幸せなのかも

2023/09/25(月) 22:11:48.17

>>142
>見れば判るコードが一番いいコードなんだよ
これに尽きる
見ればわかるコードにするのはそれなりにスキルいるからね

2023/09/25(月) 22:42:07.31

それに対する>>144の
>単純に規模が大きくなるだけでも「見ればわかるとは言えなくなるだろうに。
にID:rxWsx5B/0がどう返答するのか注目

2023/09/25(月) 22:51:51.12

「見れば分かる」にもいろいろ解釈の余地があるからな

何を見たのか、断片なのか全体なのか
何が分かったのか、その断片の処理なのか全体の機能なのか

2023/09/25(月) 22:56:08.31

規模が拡大すると、全体で何をしているのかが把握できない
という事実を振り回しているだけに見える

そんなのは当たり前の話で、だから細かく細分化したり抽象化できるようになってる
その細分化された最小パーツの段階で型ヒントが必須かどうかは、
全体の規模とは無関係な話

2023/09/25(月) 23:00:29.29

>>157
>見ればわかるコードにするのはそれなりにスキルいるからね

そこをツールでサポートできれば楽になるわけだよね

2023/09/25(月) 23:20:29.62

メリット・デメリットがあるなら
使い分ければいいじゃん

2023/09/25(月) 23:30:04.95

2万行ぐらいのプログラムは、大きい？小さい？

2023/09/25(月) 23:43:41.98

>>160
ある関数が取るパラメータの型は何か、返す値の型はなにか
その関数自体だけからでは読み取れない場合は中の処理を順に追っていく必要に迫られる
そして規模が大きくなるにつれてその探索範囲も広く深くなっていく

型ヒントの有用性は最小パーツ（数行程度の関数）であってもプロジェクトの規模に応じると考える方が自然では？

2023/09/26(火) 00:04:04.98

一見動いてるけど間違ってるのを認知する助けになるから型チェックは有難い
特に凡人ほど恩恵を受けやすい

2023/09/26(火) 00:46:46.76

VSCodeとか開発環境使ってれば圧倒的にタイプ数が違う

2023/09/26(火) 06:46:24.36

絶対に譲歩の無い議論をいつまでやるつもりなんだ
無能で暇だと言うことしか解らないぞ

2023/09/26(火) 08:36:34.19

見ればわかるコードが一番ってその通りでそれを実現するのがアノテーションなのでは？
型チェッカー入れてなくてもstrとかintとか書いてあるだけで多少便利でしょ

2023/09/26(火) 10:30:03.44

>>165
テスト書いてないの？

2023/09/26(火) 12:24:57.32

>>169
テスト書くとしてもテスト書くときにどの関数をどの型の変数が通過して…って考える必要あんだから、書かない理由にはならないでしょ
テストきちんと書くほど細心でなんで型アノテーションしないの

2023/09/26(火) 12:28:49.95

俺はそこまでしてないけど、実行時に入った変数の型見て自動でアノテーション生成してくれるツールとかもあったはず

研究、実験とか数学に使いたい人が、思考が阻害されるからつけないっていうのはわかるよ
そうじゃないのに型アノテーションに反抗してる人は、正しい道具を使ってないから文句が出るだけだと思うわ
それか用途が限定されてる小規模コードしか書いてない

2023/09/26(火) 16:30:57.25

そもそも型で躓く人はプログラミングに向いてないと思うんだよね

2023/09/26(火) 20:52:38.66

Pydanticっていうライブラリがあってだなぁ

2023/09/26(火) 20:53:40.62

>>172
まぁそれはそうだけど
JSなんかは型の曖昧さが逆に間口広くなって使う人が増えてるまであるから

2023/09/26(火) 21:32:08.30

TS触ってJSなんかにもう戻りたくないと思うかどうか

2023/09/27(水) 00:31:04.87

>>170
「テスト書かずに型ヒント書く」笑えない

2023/09/27(水) 00:55:33.55

>>170のどこをどう読んだら「テスト書かずに型ヒント書く」になるのか

2023/09/27(水) 06:30:10.21

修飾語(英語でいう目的語)がない文章に反応するから、こいういう事になる。
文章として不十分なレスはスルーが基本。

2023/09/27(水) 11:16:50.05

>>165
WindowsのAPIはboolを還す定義されていても3値戻って来たりするからな

2023/09/30(土) 00:30:05.29

tk.tk (NG用)

更に家族等などに教えて、更に￥4000×人数をGET！
https://i.imgur.com/AOHjPUT.jpg

2023/09/30(土) 00:39:07.13

>>180
金盗まれる詐欺な

2023/09/30(土) 01:56:52.88

>>180
これは知らなかった

2023/09/30(土) 07:00:11.33

>>180
グロ

2023/09/30(土) 10:20:59.78

型ヒントの導入には正直かなりショックを受けた
シンプルを旨とするPython運営がこれほどの愚行を犯すとは
コードのタイプ量は3割増しになってPythonの良さは大幅に失われるだろう
そうなる前に古いバージョンのインストールファイルをこまめに保管しておくしかない

2023/09/30(土) 10:45:18.53

使いたくなきゃ使わんでもいいってのが型ヒントのいいとこやぞ

2023/09/30(土) 11:07:31.76

働きたくない

**インボイス導入** (ｱｳｱｳｳｰ Sa89-5C2y) · 2023/09/30(土) 11:41:27.50

働いたら負け

2023/09/30(土) 12:01:20.00

使うときも全部に型ヒント付ける必要もないしな
関数の引数に付けるだけでも効果十分

2023/09/30(土) 12:36:44.89

結局チェックされないなら間違ってても通ってしまう訳で
間違ってると内容と矛盾してどっちが本当か判らなくなって
信用出来なくなって毎回内容確認するハメになって
結局効率悪くなる害悪でしかない

2023/09/30(土) 12:41:17.31

チェックされない型ヒントもどきはない方がいい
書いたならちゃんと有効活用しろ

2023/09/30(土) 13:01:40.58

>間違ってると内容と矛盾してどっちが本当か判らなくなって

どういう状況を想定してるんだろうか。

2023/09/30(土) 14:46:33.30

Pythonの文法を頑なに守りつつオブジェクト指向プログラミングを続けようという涙ぐましい努力

2023/09/30(土) 15:22:12.31

>>180
とっくに全員やってね？

2023/09/30(土) 15:55:47.06

>>189
関数入出力情報のドキュメントが信用できないってのは、適宜メンテしてね! 以外にどうしようも無いんじゃね。

2023/09/30(土) 17:28:50.98

まあどうせ観念していずれ型宣言も文法に組み込むんだろうけどさ

2023/09/30(土) 19:14:27.46

>>189
具体的なサンプルコードで状況説明してくれる？

2023/09/30(土) 22:47:55.23

仕事でExcelファイルを処理することになった
Pythonだけでどうにしようとしたけど、限界がきてVBA触ってる
色々つらいけど、特に開発環境がつらい

2023/09/30(土) 23:01:40.77

図形とかグラフとかは辛いな
excelがメインの処理の場所ならpythonでやれることは限界がある

入力データを用意するとか、設定を書いて実行ボタン押すとか、
最終結果を出力するとか、UI部分だけ使うには向いてる

2023/09/30(土) 23:05:22.23

またこの手の泣き言野郎か
今の開発者ってのは環境をお膳立てしてもらわないと何もできんのか？
設計さえちゃんとできていればテキストエディタとコマンドプロンプトで十分

2023/09/30(土) 23:09:50.32

C言語の頃は全てを記憶で書いただろうけど、
どうせ覚えられないしエディタがヒント出せばええやん、という方針で言語がデザインされるので、
装備ゼロで戦うのは大変よ

2023/09/30(土) 23:11:24.29

入力データがexcelファイルなんよな

2023/09/30(土) 23:27:08.82

>>201
Excel案件は最初からVBA一択
つらいのは適していない用途に使われて泣き言言われてるPythonだわ

2023/09/30(土) 23:39:17.77

>>202
VBAで書き始めてからそれは思いました