Pythonのお勉強 Part75

■ このスレッドは過去ログ倉庫に格納されています
2025/04/04(金) 01:47:04.18ID:UMpXJcmx0
!extend:default:vvvvv:1000:1024
!extend:default:vvvvv:1000:1024

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

※前スレ
Pythonのお勉強 Part74
https://mevius.5ch.net/test/read.cgi/tech/1726881242/
VIPQ2_EXTDAT: default:vvvvv:1000:512:: EXT was configured
VIPQ2_EXTDAT: default:vvvvv:1000:512:: EXT was configured
2025/08/10(日) 15:10:39.92ID:BWOE9N0b0
>>664, 665
y = x + 1なら「yにx + 1を割り当てる」「yをx + 1で置き換える」
x = x + 1なら「xにx + 1を割り当てる」「xをx + 1で置き換える」
で特に困らないと思うんだけど

数学の場合は変数が指し示す値が同じスコープ内で変化しない大前提があるからそれを元に「代入」を考えると「xにx+1を代入する」がおかしいという感覚になるのでは？

それともイコールじゃなくて「x ← x + 1」なら←は代入ですと言ってもしっくりくるのかな？
672デフォルトの名無しさん (ﾜｯﾁｮｲ 7a0a-WVpU)
垢版 |
2025/08/10(日) 15:49:18.97ID:swuUdv2c0
>>671
だから:=にしているプログラミング言語もある

私は「代入」という言葉を否定している人間だ。
「代入」は数学の記法の見た目と同じだから出てきた言い回しにすぎない。

仕事では「設定」などと呼ぶ。英語でもsetと呼んでいる。
2025/08/10(日) 15:53:58.39ID:BWOE9N0b0
>>666
>652に対する批判の文脈でどういう意味合いを持たせたかったのかはよく分からないな

>>648に書いてるのと同じなんだけど箱を箱のまま入れ物として取り扱う状況と箱を箱の中身が示す値として取り扱う状況の説明なくそれらを無意識に使い分けながら「一貫した説明ができる」と言ってるのを自覚して欲しかったとでも言えばいいだろうか
2025/08/10(日) 15:57:29.66ID:rGiN2SBN0
代入という訳語の気が利きすぎてるんだよな
assignのニュアンスそのままなら代入は出てこない
単に関連付けをしてるだけ
代わりに入れるという何か動きを持った訳語にしたせいで、逆に理解を阻害する
2025/08/10(日) 16:00:48.44ID:VcYsNhlgM
>>672
setには、ある既存の構造を正しく整った状態へと変えるというニュアンスがある
単なる変数の代入は変数の中身をまるっと置き換えているだけで既存の構造を変化させているわけではないし、
新しい値もそれが正しく整ったものとは限らず、ごく一時的なものだったりする
なのでより直接的なassignが用いられる
676デフォルトの名無しさん (ﾜｯﾁｮｲ 7a0a-WVpU)
垢版 |
2025/08/10(日) 16:14:57.79ID:swuUdv2c0
>>675
Pythonの話なら私は知らない。
2025/08/10(日) 16:46:12.05ID:wmWYPlFf0
Pytnonの言語仕様として「代入文」という名称で規定されているんだから、ひとまずこのスレで「代入」と呼ぶことには何の問題もないと思うけどね。それが数学における代入概念とは意味が違うから別の呼び方をすべきだというのは1つの意見としては傾聴に値すると思うけど、それはまた別の話でしょ。

>>673
それは661でコンテキスト（状況）として挙げられた要素に対応する違いであるか甚だ疑問だし、そもそも「箱を箱の中身が示す値として取り扱う」というようなふわっとした理解だから混乱するのでは。
大前提として、①名前と②名前が束縛されるメモリ領域（＝箱）とは区別される概念だけどこれはいい？　それから、②名前が束縛されるメモリ領域（＝箱）と③そこに格納されている実体（オブジェクト・値）も区別される概念だけどこっちはいいよね。たぶん、①②の区別が曖昧だから「箱を箱の中身が示す値として取り扱う」というような表現が出てくるんだと思うけど。
注意すべきは「変数」という用語の多義性で、この語は上記①〜③のいずれを指すか曖昧なまま使われがち。かつそういう曖昧な認識のまま「変数＝箱」という説明がされがちなので混乱が起きるんだと思うけどね。なお、そういう観点からいうと、646の「箱＝値」という表記の仕方も（直感的にはわかりやすいけれども）こういう曖昧な理解を助長する弊害はあるんだろう。
上記のような概念的な区別がきちんとできている限り、コンテキスト（状況）如何で変わるような話ではないということは理解しやすいと思うけどどうかな（あるいは、必要なのは概念的な区別であって、コンテキスト（状況）の場合分けではないという言い方をしても良い）。
678デフォルトの名無しさん (ﾜｯﾁｮｲ 7a0a-WVpU)
垢版 |
2025/08/10(日) 17:03:01.76ID:swuUdv2c0
箱は伝統的なプログラミング入門書が使うわかりにくい例えだしな

それより丸数字の使用が気になるぞ
679デフォルトの名無しさん (ﾜｯﾁｮｲ 7a0a-WVpU)
垢版 |
2025/08/10(日) 17:11:26.30ID:swuUdv2c0
ドキュメンテーションのない仕事をしているのがはっきりとわかるよなあ
2025/08/10(日) 17:15:06.72ID:wmWYPlFf0
メモリ領域を箱に例えるのはコンピューターのアーキテクチャーに忠実な良い例えだと思うけどね。Pytnonみたいな言語ではC言語レベルに還元しないと正確な理解に到達できないという憾みはあるが、それでもラベル（名札・荷札）のアナロジーのような曖昧なイメージに頼るよりよほど良いと思うよ。

ところで、丸数字って今でも読みづらく化けたりする？　5chみたいなところで使う分には、もう、そんなに気にしなくても良い時代かなと思っていたんだが。
2025/08/10(日) 17:20:18.25ID:rGiN2SBN0
一番気になるのは改行しないことだな
2025/08/10(日) 18:04:10.77ID:BWOE9N0b0
>>677
>>652から引用すると「y = x は（C言語レベルでは）名前（変数）yが束縛されているメモリ領域（646風にいえばyという箱）にオブジェクト"foo"のアドレス情報を入れるという形で処理されることになる。」

ここでは何の説明もなくxが「オブジェクトfoo"のアドレス情報」に変換されてるよね？

同じxでも直前の`x=“foo”`のxは箱のまま入れ物として取り扱われていたが
`y = x`のxは箱の中身が指し示す値として取り扱われている
その違いを生むのがxが評価されるコンテキストの違い
683デフォルトの名無しさん (ﾜｯﾁｮｲ 7a0a-WVpU)
垢版 |
2025/08/10(日) 18:34:46.42ID:swuUdv2c0
アセンブラのニーモニックが辞書を片手に見るか、覚えていないといけないのをわかりやすく表現しただけのものをマシン語の並び順すら知らずにこねくり回した説明をしているのは滑稽
684デフォルトの名無しさん (ﾜｯﾁｮｲ 7a0a-WVpU)
垢版 |
2025/08/10(日) 18:45:58.86ID:swuUdv2c0
>>682
CPUのレジスタがメモリのような連続した長いものでないため、コンピューターではレジスタで収まるものとそうでないものの区別がある。

コンピューターそのものがCPUとメモリという別のものを組み合わせているから、メモリへの参照なのかどうかは曖昧にしたまま進化しただけ。
2025/08/10(日) 19:11:26.73ID:wmWYPlFf0
>>682
何の説明もなくって、代入文の右辺の式が評価されるのは代入文の言語仕様そのままでしょ。何か不明確な点ってある？
代入文の左辺か右辺かの違いもコンテキスト（状況）の違いであって、そのいずれであるかによって言語処理系による名前（変数）の扱いが異なるという趣旨のことを主張したいのなら別に積極的に異論をとなえるつもりもないけれども、それについて、Pytnonの言語リファレンス等で明らかになっていることに付け加えて何か説明しなきゃいけないことってあるかな？
「箱自体を値として使う場合」（648）とか「箱を箱の中身が示す値として使う状況」（673）というのは概念上の区別が不十分であることに基づく不正確な表現・理解だと思うけど、その点が正された後になお何か理解できない点があるの？
2025/08/10(日) 19:30:23.90ID:EbzyEcBr0
2のオブジェクトがあって
x=2だとxは2のオブジェクトを参照？

オブジェクトどんだけ先に用意すんの？
687デフォルトの名無しさん (ﾜｯﾁｮｲ 7a0a-WVpU)
垢版 |
2025/08/10(日) 19:32:17.91ID:swuUdv2c0
>>686
コードに2と書いてある時点で、2もメモリ上に存在しているんだよ？
688デフォルトの名無しさん (ﾜｯﾁｮｲ 7a0a-WVpU)
垢版 |
2025/08/10(日) 19:32:51.39ID:swuUdv2c0
>>685 はただの老害
2025/08/10(日) 19:35:35.63ID:wmWYPlFf0
2がオブジェクトであることは　print( id( 2 ) ) とかしてみれば分かる。
よく使う整数はあらかじめ生成しているんじゃなかったっけ。どの範囲かは以前このスレで見たような気がするが忘れちゃった。
2025/08/10(日) 19:36:05.96ID:rGiN2SBN0
数値もオブジェクトと知った時点でその疑問に行き当たるよな
文字列がオブジェクトなのは、文字列自体が格納されたアドレスだから普通に判る
数値は整数どころか浮動小数点数でもオブジェクトで、事前に用意したら無限に要る

単にオブジェクトは必ずしもアドレスじゃなくて、数値をbit表記したものが渡されるだけ
2025/08/10(日) 19:48:29.35ID:wmWYPlFf0
RubyとかJavaScriptと違ってPytnonは即値を使わず全部PyObjectじゃなかったっけ？　正直、記憶が曖昧なので自信はないが。
2025/08/10(日) 20:18:34.90ID:WEeWhG2x0
このあたりの話かな

https://docs.python.org/ja/3/c-api/long.html
PyObject *PyLong_FromLong(long v)
戻り値: 新しい参照。 次に属します: Stable ABI.

v から新たな PyLongObject オブジェクトを生成して返します。失敗のときには NULL を返します。

現在の実装では、-5 から 256 までの全ての整数に対する整数オブジェクトの配列を保持します。この範囲の数を生成すると、実際には既存のオブジェクトに対する参照が返るようになっています。
693デフォルトの名無しさん (ﾜｯﾁｮｲ 7a0a-WVpU)
垢版 |
2025/08/10(日) 21:54:22.66ID:swuUdv2c0
Pythonは後になって「オブジェクト」という用語を使い始めた誤魔化し集団。
2025/08/10(日) 23:13:13.88ID:ZpaHmpjx0
>>685
言語仕様はおろかプログラミングにおける代入を理解してないような初心者に対して代入文とはどういうものか説明しようとして「箱 = 値」というアナロジーを使ってるんでしょ？

なのに説明できてない箇所を指摘すると「それは言語仕様を知ってればわかるからいいよね？文句ある？」みたいな開き直りをされても失笑するしかないよ
2025/08/10(日) 23:31:54.49ID:wxvmtlzV0
>>694
646は、「言語仕様はおろかプログラミングにおける代入を理解してないような初心者に対して代入文とはどういうものか説明しようとして「箱 = 値」というアナロジーを使ってる」のかもしれないが、自分はそんなつもりは全くないな。652や656で書いたような説明をそんな初心者が理解できるわけないでしょ。Pytnonのような言語の代入文をきちんと理解するにはそれなりに前提知識がいる。それが大変だから、ラベル（名札・荷札）のアナロジーのような、そこそこ良い線はいっているけれども本質的な理解からは隔たりがある説明が蔓延しているわけで。
696デフォルトの名無しさん (ﾜｯﾁｮｲ 174f-Fa+d)
垢版 |
2025/08/11(月) 10:30:52.65ID:hg5eV/6v0
CPUはレジスタに根渡ししてるだけなのにな

高級言語は余計なことやりすぎなんだよ
2025/08/11(月) 12:14:18.55ID:oIjo7VRO0
AIを作ってるが、
Pythonは型が明記されてないから、わかりずらいな…

C++のほうが見やすい
698デフォルトの名無しさん (ﾜｯﾁｮｲ b680-kDJb)
垢版 |
2025/08/11(月) 12:23:50.21ID:M47h2EOs0
正直俺もどうにかC++に持ってこれないか無駄な努力してる
whisperとかはありがたい設計なんだけど翻訳系がなー

boost::pythonもcythonも結構Cじゃ完結しないのね
699デフォルトの名無しさん (ﾜｯﾁｮｲ 5a4e-a/Iv)
垢版 |
2025/08/11(月) 14:33:28.70ID:uBk9CY7Y0
C++なら値なのか参照なのかポインタなのか一目で分かるからな
上の議論もc++なら一発で解決する
2025/08/11(月) 14:38:05.58ID:Xx9EOjxc0
deepcopy必須な再帰呼び出しをリファクタリングしてたらすっきり書けすぎて、
deepcopy部分が暗黙になってしまって逆に危険に
2025/08/12(火) 04:07:24.02ID:nMX81I590
>>687
そうなんだけどさ
整数いくつ準備してんの
あらかじめ
2025/08/12(火) 08:04:19.47ID:i9fPXIIb0
>>701
>>692
703デフォルトの名無しさん (ﾜｯﾁｮｲ df7c-J6sU)
垢版 |
2025/08/12(火) 09:10:49.53ID:rnDCu4n50
>>697
型ヒントぐらい使え
2025/08/12(火) 09:28:38.40ID:ob7DnR/R0
typingもバージョンアップのたびに機能が追加されるけれど、正直、フォローできているのは4分の1もないくらいかな。ある程度プラクティスが固まって本でも出たらそれに従うつもりではいるけれど、TypeGuardとかParamSpecとかを自分のコードで使うことはなさそう。
ヌル安全関係の演算子とかは、自分でも何とか理解できそうなので追加が可能なら欲しいかも。
2025/08/12(火) 09:32:25.25ID:lkNbq5IJ0
全部書いて自動チェック機能も常用しないと意味がない
必要なとこだけコメントで十分
2025/08/12(火) 09:59:58.99ID:46uwwH/J0
たとえばlistにリスト型宣言時に想定されていた要素型の部分型のオブジェクトを要素として入れたりすると、listは共変じゃないから型の互換性がないぞって警告が出たりするけど、そういうのにどこまで対応するのがいいのかってのがよく分からない。castして黙らせるのがいいのか、そういうものだと放置しておくのがいいのか。どちらにせよ、型ヒントを書かないコードと比べて可読性の低下に見合うメリットがあるのか。
基本的には型付けしていく方向性の方が良いんだろうなと思っているけど、今一つ自分のスタンスが固まり切らない感じ。
2025/08/12(火) 10:10:27.36ID:lkNbq5IJ0
型は決めずにいろいろ受け付けて、
想定外のが来ても意外とちゃんと動く、みたいなのがオブジェクト指向
2025/08/12(火) 10:18:49.37ID:46uwwH/J0
705と707は、方向性としては正反対なのでは。707はいわゆるダックタイピングのことだと思うけど、オブジェクト指向は静的型付けとも両立するよね。
2025/08/12(火) 10:23:41.12ID:lkNbq5IJ0
型を混同するとバグる箇所と、
意図的に型を限定しない箇所がある

混同に該当するようなことをしても、柔軟に書かれてて期待通りに動いたりもする
厳密に追えば正しく動く理由は説明できるけど、
全部隠蔽して直感的に読めるコードだけが残る
710デフォルトの名無しさん (ﾜｯﾁｮｲ 5b2a-ycC0)
垢版 |
2025/08/12(火) 10:36:41.15ID:JQsdcePx0
>>707
なんか古めかしいよね。
型は決めずに void 型ポインタとしていろいろ受け付けるみたいな。
2025/08/12(火) 10:36:56.04ID:46uwwH/J0
静的型チェッカーは、onにすると基本的には全コードについて型チェックをするものだと思っていたけど、そこは型チェッカーの設定次第で調整できるのかな。あとはAny……。
712デフォルトの名無しさん (ﾜｯﾁｮｲ 2398-a/Iv)
垢版 |
2025/08/12(火) 10:46:31.63ID:Gkg/fED60
typescriptみたいに型システムを追加したPythonのスーパーセット作ればいいんだよ
2025/08/12(火) 10:54:42.31ID:ANRO+El50
>>706
Protocol使う場面では？
structual typingでよければだけど
2025/08/12(火) 11:00:43.17ID:lkNbq5IJ0
人間の管理能力は限界があるので、
人間側が間違わずに作るんじゃなくて、
最低限のことしか考えなくても安全に動作する方向に進化している

全員でそれをやると進まないので、
一部の頭いい人だけC言語でかっちり作る両輪体制
2025/08/12(火) 11:10:42.61ID:46uwwH/J0
>>713
ProtocolについてはロバストPytnonに出てきたのをちょっと読んだくらいしか知識がないのだけど、こういうときに使えるものなのかな。: list[base] という型指定はライブラリの中でされていて書き換えるのは躊躇されるので、そうだとするとちょっと難しいのかなと。
2025/08/12(火) 13:23:41.67ID:AyHSyTNk0
>>715
それはライブラリ側の型ヒントが間違ってるか
自分が入れようとしている要素の型が間違ってるか
どちらかじゃないの？

ライブラリ側の型ヒントが間違ってると確定できてないうちは
自分が間違ってる前提で対応したほうがいいように思う
2025/08/12(火) 14:21:56.81ID:46uwwH/J0
GUIライブラリのwidgetコンテナで、格納される具体的なwidget群を属性widgeds : list[widget] に受け取るみたいな感じなんだよね。
container.widgets = [ label(), button(), textbox(), …… ] （label, button, textbox等は全てwidgetの部分型）みたいな感じで配置するんだけど、そこで706みたいな警告が出たり出なかったりする。
ありがちな状況なので、たぶん定石的な対処方法があるんじゃないかと思うんだけど。
2025/08/12(火) 15:24:09.75ID:PiEjVoIs0
>>717
list[widget]の型にwidgetのサブクラスのインスタンスを入れてもエラーにはならないはず
list[widget]の型が要求されている箇所にlist[label]型の変数を渡してるとかなのでは？
2025/08/12(火) 15:45:42.19ID:46uwwH/J0
Pytnonの型チェックはあくまでもヒントだからエラーというか警告だけどね。自分も比較的最近知ったことだから勘違いがあるかもしれないけれど、listはmutableコンテナだから共変ではないんだって。だから、A <: B（Bが上位型でAはその部分型）のときでもlist[A] <: list[B] にはならないらしいよ。
2025/08/12(火) 16:10:13.74ID:46uwwH/J0
たしかにlistの要素として、その型宣言時の要素型のサブクラスのインスタンスを入れるだけなら特に問題ないはずだとは自分も思うんだよね。
717のcontainer.widgets = [ label(), button(), textbox(), …… ] は、両辺の式の型の間に互換性がない（listは非変なので）点に問題があるということだとすると、container.widget.extend( …… ) とかの書き方にしたら大丈夫なんだろうか。ライブラリのリファレンスとかにはそういう書き方は出てこなかったけど。
2025/08/12(火) 16:18:25.12ID:PiEjVoIs0
>>719
型チェッカーがエラーと報告するならエラーでいいよ

listが共変でないというのは要素型のサブクラスはlistに入れられない話ではない

これはNG
mylist: list[label] = [label]
widgets = mylist

これはOK
widgets = [label]

これもOK
widgets = [label, button, textbox]
2025/08/12(火) 16:34:38.20ID:PiEjVoIs0
OKなはずなのにエラーが出てるのなら最小限の再現コードをpyrightのplaygroundにでも上げてもらったほうがいいかもね
2025/08/12(火) 16:57:06.52ID:46uwwH/J0
なるほど、たしかにそれだと警告は出ないね。短い再現コードが出せるようならやってみるけどちょっと難しそうかな。たぶん代入文の右辺について、型チェッカーが（list[widget]と互換性のない）型情報をコード内の別のところから得ちゃっているということなんだろうと思うけど。
2025/08/12(火) 19:52:51.31ID:CDoCkaEH0
>>723
型を明記しないとエラーとかってできる？
VBAみたいに

C++のほうが慣れてるから、そのほうがええわ
2025/08/12(火) 21:31:27.14ID:i9fPXIIb0
エラーにできるかというのが、静的型付けができていないコードの実行を自動的に抑止できるかという意味なら、Pytnon単体ではムリじゃない？　あくまでも型「注釈」に過ぎないわけだし。でも、型チェッカーの方でそういう設定はあるんじゃないかなぁ。
2025/08/12(火) 22:31:56.05ID:jU+JMCmR0
>>724
pyrightのstrict modeを試してみるといいと思う
2025/08/12(火) 22:41:38.16ID:nRaft4INM
Pythonの型ヒントって型推論が許されてるけどどこまでそれが効くかはチェッカーの実装依存なんだよね
つまりチェッカーからすると型が不明というのは多くの場合において自身の型推論がショボいことを意味するわけで、
不明だからエラーにするというのは筋が通らないわけよ
せいぜい引数と戻り値に方指定を必須にするくらいだね
2025/08/12(火) 23:05:23.88ID:DyWlhw4u0
実行時まで型が決まらん、というのまであるしなあ
2025/08/12(火) 23:06:06.49ID:6cjc6Wvo0
商用プログラム書くならパフォーマンス犠牲になってもランタイムの型チェックがほしい
こんどしれっとtypeguardいれてみようかな
AI支援もあるし猛烈に反対はされなそう
2025/08/13(水) 06:35:34.74ID:o5KTBnUB0
>>726
まあでも、
やっぱ、オレみたいなやっぱ要望はたくさんあるんだな

型を明記して欲しいって人
2025/08/13(水) 08:37:10.53ID:+sjCYsF70
>>730
問題は>>727の通り、どこまで明記すれば不明でなくなるのかがPythonの仕様上不明であること
例えば x = f() において、fの戻り値がstrとして型指定されている場合、右辺の式 f() の型は何になるだろう? 左辺で宣言された変数xの型はどうか?
どっちも当然strと思うかもしれないが、これ正確にはどちらも型推論が必要で、なんと型チェッカーの実装依存なんだよね
x: str = typing.cast(str, f())
もし可能な限り明記しようとすればこうなるが、これでもなお実装依存でないとは言えない
2025/08/13(水) 09:44:46.84ID:/jTyGuwU0
型付け・型検査の目的は型の不整合の有無を確認することだから、式の型が1つに確定できるならそれが最も分かりやすいとは思うけど、必ずしも1つに確定できなくても（たとえば式の型としてa型、b型、c型の3つの可能性があって、そのいずれについても）型の不整合が生じないことが確認できているのであれば、それで型付け・型検査としての役割は果たしているようにも思うけど。
2025/08/13(水) 09:48:15.23ID:rfdqQR7l0
動的型付け言語を静的型付け言語のように取り扱うのが間違い
無管理よりは何かやれることあるだろうという模索の最中だけど、本質的に困難
2025/08/13(水) 10:05:06.70ID:IjqUTXVC0
もちろん、静的型付け言語と全面的に同じことができるわけではないけれども、部分的にではあれ良いところを真似することはできるし、邪魔くさいという人は従来どおりのスタイルで書くこともできる。型指定をアノテーションにとどめるというのはそんなに悪いアイデアではないと思うけどなー。
735デフォルトの名無しさん (ｱｳｱｳｳｰ Sac7-Kgix)
垢版 |
2025/08/13(水) 12:39:57.08ID:U7zZSy+Fa
PyhtonのListが型限定されたら嫌だな
もちろんPyObjectとしては限定されてるが
そういう意味じゃないんだ
2025/08/13(水) 14:26:42.51ID:52kJFnMW0
>>727
ESLint だと明示的でない any を警告するオプションがあったりする。
型が不明という状況がその型推論がショボいことを意味したりはしないと思うがな。

ただ実用上の問題としては、型ヒントを提供していないモジュールが多いんで
警告が出まくる可能性があること。
2025/08/13(水) 16:15:18.85ID:jrIykVeu0
自分はpylanceのbasicでちょうどいいくらいだわ
738デフォルトの名無しさん (ﾜｯﾁｮｲ 3efe-bxVO)
垢版 |
2025/08/13(水) 17:18:57.17ID:vtzVqfUP0
labelStudioのインストールについて質問してもいいですか？
WindowsパソコンでlabelStudioの最新版をインストールしたのですがコマンドプロンプトでpipコードを入力してもファイルが見つかりませんとなってlabelStudioが起動出来ません。
わかる方いますか？
2025/08/13(水) 18:47:31.75ID:God64kkW0
>>738
https://labelstud.io/learn/getting-started-with-label-studio/
これでためしてみて
Dockerなんて要らないとおもうかもしれないけど
それならまずそんなところで躓かないくらいのオタクになる必要がある
740デフォルトの名無しさん (ﾜｯﾁｮｲ 3efe-bxVO)
垢版 |
2025/08/13(水) 19:30:06.31ID:vtzVqfUP0
>>739
Dockerとはなんぞや？なレベルなんてちんぷんかんぷんです。
ずぶの素人にはインストールすらむずいっす
741デフォルトの名無しさん (ﾜｯﾁｮｲ dff2-ChRm)
垢版 |
2025/08/15(金) 00:02:17.57ID:UemuT+6G0
pyxが出たよ

…何するツール？

https://astral.sh/pyx
742デフォルトの名無しさん (ﾜｯﾁｮｲ 41f0-/HUD)
垢版 |
2025/08/19(火) 07:51:45.77ID:fyqgDdBA0
配列でもdict使えば分かりやすいし変数名で何入るかだいたい分かるやろ
pythonて組込みには使わないし型なんているんか🐼
2025/08/19(火) 09:47:34.16ID:ndmX+Emn0
ある程度規模が大きいプログラムでないと型のありがたみは分からないと一般的に言われているのでは。個人的には一応できるだけ型は付けるようにしているけど、可読性の低下に見合うメリットを実感できているかと言われると微妙なところかな。
typingも急速に複雑化したよねー
744デフォルトの名無しさん (ﾜｯﾁｮｲ 6130-im2P)
垢版 |
2025/08/19(火) 11:31:08.50ID:2nwbx/Cn0
型記述すると可読性が低下すると思っている人と
型記述しないと可読性が低下すると思っている人がいる
2025/08/19(火) 11:53:03.68ID:CS+/mYIY0
使わない理由は手間に見合うかどうかなんだとおもう
コードのノイズになるってんならIDEに型ヒント部分を隠す拡張があればいい
2025/08/19(火) 12:50:32.05ID:AwWeWqwl0
型ヒントを一時的に隠す機能は、たしかにちょっと欲しいかも。というか、もうあるのかもしれないけど。
他人が書いたコードとか、自分が書いたコードでも内容をだいぶ忘れてしまったコードを読むときは型ヒントが大いに助けになるけど、ある程度内容を把握しているコードだと型ヒントがない方が読みやすいってことは結構あるだろうとは思う。
747デフォルトの名無しさん (ﾜｯﾁｮｲ 214b-ZBQJ)
垢版 |
2025/08/19(火) 17:20:40.65ID:EZlqtCJf0
型ヒントないとメソッドに飛べないでしょ
効率的にコーディングするために必要だよ型ヒントは
2025/08/20(水) 14:50:38.31ID:v4jtEgpO0
lambdaの本体に式しか含められないという制限は、どういう考慮からなんだっけ？　名前あり関数を定義すれば済む話なのでそこまで不便というわけではないのだけれど、lambdaの中にそのまま書けたほうが自然なのになと思うことはちょくちょくある。
749デフォルトの名無しさん (ﾌﾞｰｲﾓ MMb3-y2EG)
垢版 |
2025/08/20(水) 16:32:51.46ID:qKO8yNcaM
>>748
フレームワークの概念がないのか？
2025/08/20(水) 17:15:55.62ID:V8h3cYb/0
>>748
式の中にステートメントを入れられないという大前提を覆すとなると影響が大きすぎるしそもそも思想に合わなかったからだと思う
assignment expressionの導入を嫌がってたのにも通じる話
2025/08/20(水) 19:37:21.46ID:v4jtEgpO0
JavaScriptの関数定義式のイメージで、lambdaを式ではなく文にしたらどうかという前提で考えていたんだが、仮に文にするにしても「値を持つが式文ではない特殊な文」みたいなカテゴリを作るのは大変か。そうするとやむを得ないところかね。
2025/08/20(水) 21:05:15.22ID:z8I7zAVw0
羊のラムの綴りはlamb
一旦lambを書いてからdaを付けると間違わない
753デフォルトの名無しさん (ｵｲｺﾗﾐﾈｵ MMa5-1GGU)
垢版 |
2025/08/20(水) 22:25:29.24ID:WlXb3anFM
>>737
それでもウザいかな。nodeを自分でインストールする必要ないということで、basedpyrightを使ってみたけど、デフォルトのあまりにうるささに即削除した。
uvとかruffだっけ？のチームが最近始めたやつに少し期待している。
2025/08/20(水) 22:32:03.53ID:ABvMeeh/0
AIをゴリゴリ使って基幹ソフトをRPAとPythonで便利にする仕組みを社内投稿したら、会社でバズってなんかすごいスキルとか言われて困ってる 制作したことに偽りは無いけど、専門部署に呼ばれても知らんし（泣）そもそも制作のモチベーションは現場にあるから専門部署に行ってもしょうがない 現場のおじさんでも作れる時代になった事がエポックメイクな事なのに
755デフォルトの名無しさん (ﾜｯﾁｮｲ 9321-/HUD)
垢版 |
2025/08/21(木) 04:26:17.36ID:W7b3RP8P0
pyrightなんでtypescript使ってるんだろう
node系のやつ重いしなんか不具合出るから嫌い
756デフォルトの名無しさん (ﾜｯﾁｮｲ 9321-/HUD)
垢版 |
2025/08/21(木) 04:37:15.98ID:W7b3RP8P0
pylspがいい？
2025/08/21(木) 10:33:12.22ID:5TY3/WJ10
VSCodeでPylanceを使っているけど、そこまで動作が重いとは感じないかな。警告がいっぱい出て鬱陶しいというのは分かるけど。
2025/08/21(木) 11:42:59.90ID:sU8D6GG4M
AIを使う業務ソフトならすごいけど
AIを使って作ったソフトって普通のソフトだよね
2025/08/21(木) 12:17:55.74ID:xRU3TdBF0
AIを使（って作）ったソフト
760デフォルトの名無しさん (ﾜｯﾁｮｲ ab7f-vIW/)
垢版 |
2025/08/21(木) 13:08:37.56ID:2lMxcY0H0
AIを使って作った、AIを使う業務ソフトはどうなんだ？
2025/08/21(木) 14:36:13.83ID:89YTIbF70
AIを使って作ったAIを使う業務ソフトを作るAIを使って作ったAIを使う業務ソフト
762デフォルトの名無しさん (ﾜｯﾁｮｲ 115f-YAjS)
垢版 |
2025/08/21(木) 21:05:36.45ID:qlXUTR3c0
AIでなんでも作れるならフォトショップと同等のものをAIに作らせてくれや(´・ω・`)
2025/08/23(土) 09:41:55.38ID:6fcByJBp0
言語リファレンスで、型引数リストが複合文の最後に入れられているけど、あれって文なのかな？　暫定的に置いているだけ？
764デフォルトの名無しさん (ﾜｯﾁｮｲ c92a-68+F)
垢版 |
2025/08/23(土) 19:28:41.00ID:erudRyon0
言語リファレンス中を探し回れってか。
765デフォルトの名無しさん (ｱｳｱｳｳｰ Sa45-im2P)
垢版 |
2025/08/23(土) 19:47:31.14ID:pcHjlSL+a
BNF
2025/08/23(土) 22:20:23.66ID:dVERUN7r0
>>763
複合文を構成する要素だから複合文のページで説明してるだけ
式や単純文のところで説明してたらおかしい
2025/08/24(日) 01:08:14.15ID:+j+JozVj0
それ自体としては文ではないという点に引っかかりをおぼえていたんだが、式のところに演算子についての記述があるようなものか。
ただ、type文は単純文なので、単純文の構文要素になる場合もある……が、そこはまぁ分かるでしょってことで複合文のところにあるんだろうな。
2025/08/24(日) 02:49:47.32ID:Y0IRLNQN0
Pythonの内包表記やばいな
こんなんでよくperlは読みにくいとか罵れるな
2025/08/24(日) 07:50:22.46ID:rMBqpZLF0
慣れるとあれが自然言語のように読めるし、編集せずに先頭から書いていける
2025/08/24(日) 08:22:02.52ID:+j+JozVj0
要素を表現する式やinの後が長大になることもしばしばあって、そういう場合はたしかに読みにくいんだけど、基本的にはすごい便利な構文だと思うけどなぁ。発想としては集合の内包表記っぽく書けるようにしようということなんだろうし、やっぱりHaskellは偉大だわ。

たとえばlist内包なら[ （要素を表す式） for （ループ変数・iterable変数） in （iterable） ] で、要素を表す式を書くのにループ変数・iterable変数を使うことができるというだけなので慣れればそんなに難しくないよ。キーワードのforとinが短くて埋没しやすいのが読みにくさを感じる原因なのかもしれない。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況