Pythonのお勉強 Part75 (794ﾚｽ)
上下前次1-新
1: (ﾜｯﾁｮｲ 33d8-PysV) 04/04(金)01:47 ID:UMpXJcmx0(1/4) AAS
!extend:default:vvvvv:1000:1024
!extend:default:vvvvv:1000:1024
↑スレ立てる毎に減るので、減ってたら３つに補充すること。
※前スレ
Pythonのお勉強 Part74
2chｽﾚ:tech
VIPQ2_EXTDAT: default:vvvvv:1000:512:: EXT was configured VIPQ2_EXTDAT: default:vvvvv:1000:512:: EXT was configured
668: (ﾜｯﾁｮｲ 0754-mJPu) 08/10(日)13:45 ID:rGiN2SBN0(7/10) AAS
荷札という名称が悪すぎるわw
実体の所有者(複数可)が誰か判るような管理リスト、みたいなイメージ
実際にはリストじゃないからこの時点で乖離があるけど
登記簿とか株券の裏を複数所有可能にした的な
所有してる訳でもないのでズレる
なんで「参照」の一言を参照使わずに説明するのがこんなに困難なのか
669: (ﾜｯﾁｮｲ 1af2-ZDX3) 08/10(日)14:04 ID:WyYSCohm0(2/2) AAS
>>666
t = (x, y)
u = t
これは、荷札xの付いた実体に対して荷札t[0]を、荷札yの実体に対して同様に荷札t[1]を貼り付ける、
同時に、荷札t[0]とt[1]を管理するために”t[0], t[1]”と書かれた台帳を作成し、その台帳に荷札uを付けると解釈すればよい
これは参照の向きを逆に捉えて参照される側が参照元を記憶していると考えているだけなので、基本的にはこのような説明で矛盾は生じない
荷札名から実体を探すのが大変だという問題は残るけどね
670: (ﾜｯﾁｮｲ f6ce-1ngM) 08/10(日)14:29 ID:wmWYPlFf0(4/9) AAS
仮にそれをそのまま実装に反映させるなら、Pytnonオブジェクトに（被参照カウント数に加えて）参照元のリストも持たせるってことでしょ。
そうではなく、単に解釈モデルに過ぎないってことなら、内部実装がそうなっているわけでもないのに、あえてそんな不自然な解釈モデルを作ってまで荷札（ラベル・名札）のアナロジーに拘る意味ってあるのかな？ たとえばそれで、（666でちょっと触れた）tupleの要素であるlistの要素を変更してもtupleのimmutabilityに反しないことの説明がしやすくなったりする？
671(1): (ﾜｯﾁｮｲ 7601-AJBo) 08/10(日)15:10 ID:BWOE9N0b0(1/3) AAS
>>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(1): (ﾜｯﾁｮｲ 7a0a-WVpU) 08/10(日)15:49 ID:swuUdv2c0(3/11) AAS
>>671
だから:=にしているプログラミング言語もある
私は「代入」という言葉を否定している人間だ。
「代入」は数学の記法の見た目と同じだから出てきた言い回しにすぎない。
仕事では「設定」などと呼ぶ。英語でもsetと呼んでいる。
673(1): (ﾜｯﾁｮｲ 7601-AJBo) 08/10(日)15:53 ID:BWOE9N0b0(2/3) AAS
>>666
>652に対する批判の文脈でどういう意味合いを持たせたかったのかはよく分からないな
>>648に書いてるのと同じなんだけど箱を箱のまま入れ物として取り扱う状況と箱を箱の中身が示す値として取り扱う状況の説明なくそれらを無意識に使い分けながら「一貫した説明ができる」と言ってるのを自覚して欲しかったとでも言えばいいだろうか
674: (ﾜｯﾁｮｲ 0754-mJPu) 08/10(日)15:57 ID:rGiN2SBN0(8/10) AAS
代入という訳語の気が利きすぎてるんだよな
assignのニュアンスそのままなら代入は出てこない
単に関連付けをしてるだけ
代わりに入れるという何か動きを持った訳語にしたせいで、逆に理解を阻害する
675(1): (ﾍﾞｰｲﾓ MM06-ZDX3) 08/10(日)16:00 ID:VcYsNhlgM(1) AAS
>>672
setには、ある既存の構造を正しく整った状態へと変えるというニュアンスがある
単なる変数の代入は変数の中身をまるっと置き換えているだけで既存の構造を変化させているわけではないし、
新しい値もそれが正しく整ったものとは限らず、ごく一時的なものだったりする
なのでより直接的なassignが用いられる
676: (ﾜｯﾁｮｲ 7a0a-WVpU) 08/10(日)16:14 ID:swuUdv2c0(4/11) AAS
>>675
Pythonの話なら私は知らない。
677(1): (ﾜｯﾁｮｲ f64c-1ngM) 08/10(日)16:46 ID:wmWYPlFf0(5/9) AAS
Pytnonの言語仕様として「代入文」という名称で規定されているんだから、ひとまずこのスレで「代入」と呼ぶことには何の問題もないと思うけどね。それが数学における代入概念とは意味が違うから別の呼び方をすべきだというのは1つの意見としては傾聴に値すると思うけど、それはまた別の話でしょ。
>>673
それは661でコンテキスト（状況）として挙げられた要素に対応する違いであるか甚だ疑問だし、そもそも「箱を箱の中身が示す値として取り扱う」というようなふわっとした理解だから混乱するのでは。
大前提として、①名前と②名前が束縛されるメモリ領域（＝箱）とは区別される概念だけどこれはいい？ それから、②名前が束縛されるメモリ領域（＝箱）と③そこに格納されている実体（オブジェクト・値）も区別される概念だけどこっちはいいよね。たぶん、①②の区別が曖昧だから「箱を箱の中身が示す値として取り扱う」というような表現が出てくるんだと思うけど。
注意すべきは「変数」という用語の多義性で、この語は上記①〜③のいずれを指すか曖昧なまま使われがち。かつそういう曖昧な認識のまま「変数＝箱」という説明がされがちなので混乱が起きるんだと思うけどね。なお、そういう観点からいうと、646の「箱＝値」という表記の仕方も（直感的にはわかりやすいけれども）こういう曖昧な理解を助長する弊害はあるんだろう。
上記のような概念的な区別がきちんとできている限り、コンテキスト（状況）如何で変わるような話ではないということは理解しやすいと思うけどどうかな（あるいは、必要なのは概念的な区別であって、コンテキスト（状況）の場合分けではないという言い方をしても良い）。
678: (ﾜｯﾁｮｲ 7a0a-WVpU) 08/10(日)17:03 ID:swuUdv2c0(5/11) AAS
箱は伝統的なプログラミング入門書が使うわかりにくい例えだしな
それより丸数字の使用が気になるぞ
679: (ﾜｯﾁｮｲ 7a0a-WVpU) 08/10(日)17:11 ID:swuUdv2c0(6/11) AAS
ドキュメンテーションのない仕事をしているのがはっきりとわかるよなあ
680: (ﾜｯﾁｮｲ f64c-1ngM) 08/10(日)17:15 ID:wmWYPlFf0(6/9) AAS
メモリ領域を箱に例えるのはコンピューターのアーキテクチャーに忠実な良い例えだと思うけどね。Pytnonみたいな言語ではC言語レベルに還元しないと正確な理解に到達できないという憾みはあるが、それでもラベル（名札・荷札）のアナロジーのような曖昧なイメージに頼るよりよほど良いと思うよ。
ところで、丸数字って今でも読みづらく化けたりする？ 5chみたいなところで使う分には、もう、そんなに気にしなくても良い時代かなと思っていたんだが。
681: (ﾜｯﾁｮｲ 0754-mJPu) 08/10(日)17:20 ID:rGiN2SBN0(9/10) AAS
一番気になるのは改行しないことだな
682(2): (ﾜｯﾁｮｲ 7601-AJBo) 08/10(日)18:04 ID:BWOE9N0b0(3/3) AAS
>>677
>>652から引用すると「y = x は（C言語レベルでは）名前（変数）yが束縛されているメモリ領域（646風にいえばyという箱）にオブジェクト"foo"のアドレス情報を入れるという形で処理されることになる。」
ここでは何の説明もなくxが「オブジェクトfoo"のアドレス情報」に変換されてるよね？
同じxでも直前の`x=“foo”`のxは箱のまま入れ物として取り扱われていたが
`y = x`のxは箱の中身が指し示す値として取り扱われている
その違いを生むのがxが評価されるコンテキストの違い
683: (ﾜｯﾁｮｲ 7a0a-WVpU) 08/10(日)18:34 ID:swuUdv2c0(7/11) AAS
アセンブラのニーモニックが辞書を片手に見るか、覚えていないといけないのをわかりやすく表現しただけのものをマシン語の並び順すら知らずにこねくり回した説明をしているのは滑稽
684: (ﾜｯﾁｮｲ 7a0a-WVpU) 08/10(日)18:45 ID:swuUdv2c0(8/11) AAS
>>682
CPUのレジスタがメモリのような連続した長いものでないため、コンピューターではレジスタで収まるものとそうでないものの区別がある。
コンピューターそのものがCPUとメモリという別のものを組み合わせているから、メモリへの参照なのかどうかは曖昧にしたまま進化しただけ。
685(2): (ﾜｯﾁｮｲ f64c-1ngM) 08/10(日)19:11 ID:wmWYPlFf0(7/9) AAS
>>682
何の説明もなくって、代入文の右辺の式が評価されるのは代入文の言語仕様そのままでしょ。何か不明確な点ってある？
代入文の左辺か右辺かの違いもコンテキスト（状況）の違いであって、そのいずれであるかによって言語処理系による名前（変数）の扱いが異なるという趣旨のことを主張したいのなら別に積極的に異論をとなえるつもりもないけれども、それについて、Pytnonの言語リファレンス等で明らかになっていることに付け加えて何か説明しなきゃいけないことってあるかな？
「箱自体を値として使う場合」（648）とか「箱を箱の中身が示す値として使う状況」（673）というのは概念上の区別が不十分であることに基づく不正確な表現・理解だと思うけど、その点が正された後になお何か理解できない点があるの？
686(1): (ﾜｯﾁｮｲ 3e5f-ZDX3) 08/10(日)19:30 ID:EbzyEcBr0(1) AAS
2のオブジェクトがあって
x=2だとxは2のオブジェクトを参照？
オブジェクトどんだけ先に用意すんの？
687(1): (ﾜｯﾁｮｲ 7a0a-WVpU) 08/10(日)19:32 ID:swuUdv2c0(9/11) AAS
>>686
コードに2と書いてある時点で、2もメモリ上に存在しているんだよ？
688: (ﾜｯﾁｮｲ 7a0a-WVpU) 08/10(日)19:32 ID:swuUdv2c0(10/11) AAS
>>685 はただの老害
689: (ﾜｯﾁｮｲ f64c-1ngM) 08/10(日)19:35 ID:wmWYPlFf0(8/9) AAS
2がオブジェクトであることは print( id( 2 ) ) とかしてみれば分かる。
よく使う整数はあらかじめ生成しているんじゃなかったっけ。どの範囲かは以前このスレで見たような気がするが忘れちゃった。
690: (ﾜｯﾁｮｲ 0754-mJPu) 08/10(日)19:36 ID:rGiN2SBN0(10/10) AAS
数値もオブジェクトと知った時点でその疑問に行き当たるよな
文字列がオブジェクトなのは、文字列自体が格納されたアドレスだから普通に判る
数値は整数どころか浮動小数点数でもオブジェクトで、事前に用意したら無限に要る
単にオブジェクトは必ずしもアドレスじゃなくて、数値をbit表記したものが渡されるだけ
691: (ﾜｯﾁｮｲ f64c-1ngM) 08/10(日)19:48 ID:wmWYPlFf0(9/9) AAS
RubyとかJavaScriptと違ってPytnonは即値を使わず全部PyObjectじゃなかったっけ？ 正直、記憶が曖昧なので自信はないが。
692(1): (ﾜｯﾁｮｲ 1a79-MCtg) 08/10(日)20:18 ID:WEeWhG2x0(1) AAS
このあたりの話かな
外部ﾘﾝｸ[html]:docs.python.org
PyObject *PyLong_FromLong(long v)
戻り値: 新しい参照。 次に属します: Stable ABI.
v から新たな PyLongObject オブジェクトを生成して返します。失敗のときには NULL を返します。
現在の実装では、-5 から 256 までの全ての整数に対する整数オブジェクトの配列を保持します。この範囲の数を生成すると、実際には既存のオブジェクトに対する参照が返るようになっています。
693: (ﾜｯﾁｮｲ 7a0a-WVpU) 08/10(日)21:54 ID:swuUdv2c0(11/11) AAS
Pythonは後になって「オブジェクト」という用語を使い始めた誤魔化し集団。
694(1): (ﾜｯﾁｮｲ de01-AJBo) 08/10(日)23:13 ID:ZpaHmpjx0(1) AAS
>>685
言語仕様はおろかプログラミングにおける代入を理解してないような初心者に対して代入文とはどういうものか説明しようとして「箱 = 値」というアナロジーを使ってるんでしょ？
なのに説明できてない箇所を指摘すると「それは言語仕様を知ってればわかるからいいよね？文句ある？」みたいな開き直りをされても失笑するしかないよ
695: (ﾜｯﾁｮｲ 232c-1ngM) 08/10(日)23:31 ID:wxvmtlzV0(2/2) AAS
>>694
646は、「言語仕様はおろかプログラミングにおける代入を理解してないような初心者に対して代入文とはどういうものか説明しようとして「箱 = 値」というアナロジーを使ってる」のかもしれないが、自分はそんなつもりは全くないな。652や656で書いたような説明をそんな初心者が理解できるわけないでしょ。Pytnonのような言語の代入文をきちんと理解するにはそれなりに前提知識がいる。それが大変だから、ラベル（名札・荷札）のアナロジーのような、そこそこ良い線はいっているけれども本質的な理解からは隔たりがある説明が蔓延しているわけで。
696: (ﾜｯﾁｮｲ 174f-Fa+d) 08/11(月)10:30 ID:hg5eV/6v0(1) AAS
CPUはレジスタに根渡ししてるだけなのにな
高級言語は余計なことやりすぎなんだよ
697(1): (ﾜｯﾁｮｲ 9a02-QbuV) 08/11(月)12:14 ID:oIjo7VRO0(1) AAS
AIを作ってるが、
Pythonは型が明記されてないから、わかりずらいな…
C++のほうが見やすい
698: (ﾜｯﾁｮｲ b680-kDJb) 08/11(月)12:23 ID:M47h2EOs0(1) AAS
正直俺もどうにかC++に持ってこれないか無駄な努力してる
whisperとかはありがたい設計なんだけど翻訳系がなー
boost::pythonもcythonも結構Cじゃ完結しないのね
699: (ﾜｯﾁｮｲ 5a4e-a/Iv) 08/11(月)14:33 ID:uBk9CY7Y0(1) AAS
C++なら値なのか参照なのかポインタなのか一目で分かるからな
上の議論もc++なら一発で解決する
700: (ﾜｯﾁｮｲ 0754-mJPu) 08/11(月)14:38 ID:Xx9EOjxc0(1) AAS
deepcopy必須な再帰呼び出しをリファクタリングしてたらすっきり書けすぎて、
deepcopy部分が暗黙になってしまって逆に危険に
701(1): (ﾜｯﾁｮｲ 3e3e-ZDX3) 08/12(火)04:07 ID:nMX81I590(1) AAS
>>687
そうなんだけどさ
整数いくつ準備してんの
あらかじめ
702: (ﾜｯﾁｮｲ 4e10-1ngM) 08/12(火)08:04 ID:i9fPXIIb0(1/2) AAS
>>701
>>692
703: (ﾜｯﾁｮｲ df7c-J6sU) 08/12(火)09:10 ID:rnDCu4n50(1) AAS
>>697
型ヒントぐらい使え
704: (ﾜｯﾁｮｲ 230f-1ngM) 08/12(火)09:28 ID:ob7DnR/R0(1) AAS
typingもバージョンアップのたびに機能が追加されるけれど、正直、フォローできているのは4分の1もないくらいかな。ある程度プラクティスが固まって本でも出たらそれに従うつもりではいるけれど、TypeGuardとかParamSpecとかを自分のコードで使うことはなさそう。
ヌル安全関係の演算子とかは、自分でも何とか理解できそうなので追加が可能なら欲しいかも。
705: (ﾜｯﾁｮｲ 0754-mJPu) 08/12(火)09:32 ID:lkNbq5IJ0(1/4) AAS
全部書いて自動チェック機能も常用しないと意味がない
必要なとこだけコメントで十分
706(1): (ﾜｯﾁｮｲ f6c1-1ngM) 08/12(火)09:59 ID:46uwwH/J0(1/8) AAS
たとえばlistにリスト型宣言時に想定されていた要素型の部分型のオブジェクトを要素として入れたりすると、listは共変じゃないから型の互換性がないぞって警告が出たりするけど、そういうのにどこまで対応するのがいいのかってのがよく分からない。castして黙らせるのがいいのか、そういうものだと放置しておくのがいいのか。どちらにせよ、型ヒントを書かないコードと比べて可読性の低下に見合うメリットがあるのか。
基本的には型付けしていく方向性の方が良いんだろうなと思っているけど、今一つ自分のスタンスが固まり切らない感じ。
707(1): (ﾜｯﾁｮｲ 0754-mJPu) 08/12(火)10:10 ID:lkNbq5IJ0(2/4) AAS
型は決めずにいろいろ受け付けて、
想定外のが来ても意外とちゃんと動く、みたいなのがオブジェクト指向
708: (ﾜｯﾁｮｲ f6c1-1ngM) 08/12(火)10:18 ID:46uwwH/J0(2/8) AAS
705と707は、方向性としては正反対なのでは。707はいわゆるダックタイピングのことだと思うけど、オブジェクト指向は静的型付けとも両立するよね。
709: (ﾜｯﾁｮｲ 0754-mJPu) 08/12(火)10:23 ID:lkNbq5IJ0(3/4) AAS
型を混同するとバグる箇所と、
意図的に型を限定しない箇所がある
混同に該当するようなことをしても、柔軟に書かれてて期待通りに動いたりもする
厳密に追えば正しく動く理由は説明できるけど、
全部隠蔽して直感的に読めるコードだけが残る
710: (ﾜｯﾁｮｲ 5b2a-ycC0) 08/12(火)10:36 ID:JQsdcePx0(1) AAS
>>707
なんか古めかしいよね。
型は決めずに void 型ポインタとしていろいろ受け付けるみたいな。
711: (ﾜｯﾁｮｲ f6c1-1ngM) 08/12(火)10:36 ID:46uwwH/J0(3/8) AAS
静的型チェッカーは、onにすると基本的には全コードについて型チェックをするものだと思っていたけど、そこは型チェッカーの設定次第で調整できるのかな。あとはAny……。
712: (ﾜｯﾁｮｲ 2398-a/Iv) 08/12(火)10:46 ID:Gkg/fED60(1) AAS
typescriptみたいに型システムを追加したPythonのスーパーセット作ればいいんだよ
713(1): (ﾜｯﾁｮｲ de01-/C6k) 08/12(火)10:54 ID:ANRO+El50(1) AAS
>>706
Protocol使う場面では？
structual typingでよければだけど
714: (ﾜｯﾁｮｲ 0754-mJPu) 08/12(火)11:00 ID:lkNbq5IJ0(4/4) AAS
人間の管理能力は限界があるので、
人間側が間違わずに作るんじゃなくて、
最低限のことしか考えなくても安全に動作する方向に進化している
全員でそれをやると進まないので、
一部の頭いい人だけC言語でかっちり作る両輪体制
715(1): (ﾜｯﾁｮｲ f6c1-1ngM) 08/12(火)11:10 ID:46uwwH/J0(4/8) AAS
>>713
ProtocolについてはロバストPytnonに出てきたのをちょっと読んだくらいしか知識がないのだけど、こういうときに使えるものなのかな。: list[base] という型指定はライブラリの中でされていて書き換えるのは躊躇されるので、そうだとするとちょっと難しいのかなと。
716: (ﾜｯﾁｮｲ cb01-/C6k) 08/12(火)13:23 ID:AyHSyTNk0(1) AAS
>>715
それはライブラリ側の型ヒントが間違ってるか
自分が入れようとしている要素の型が間違ってるか
どちらかじゃないの？
ライブラリ側の型ヒントが間違ってると確定できてないうちは
自分が間違ってる前提で対応したほうがいいように思う
717(1): (ﾜｯﾁｮｲ f641-1ngM) 08/12(火)14:21 ID:46uwwH/J0(5/8) AAS
GUIライブラリのwidgetコンテナで、格納される具体的なwidget群を属性widgeds : list[widget] に受け取るみたいな感じなんだよね。
container.widgets = [ label(), button(), textbox(), …… ] （label, button, textbox等は全てwidgetの部分型）みたいな感じで配置するんだけど、そこで706みたいな警告が出たり出なかったりする。
ありがちな状況なので、たぶん定石的な対処方法があるんじゃないかと思うんだけど。
718: (ﾜｯﾁｮｲ df01-/C6k) 08/12(火)15:24 ID:PiEjVoIs0(1/3) AAS
>>717
list[widget]の型にwidgetのサブクラスのインスタンスを入れてもエラーにはならないはず
list[widget]の型が要求されている箇所にlist[label]型の変数を渡してるとかなのでは？
719(1): (ﾜｯﾁｮｲ f641-1ngM) 08/12(火)15:45 ID:46uwwH/J0(6/8) AAS
Pytnonの型チェックはあくまでもヒントだからエラーというか警告だけどね。自分も比較的最近知ったことだから勘違いがあるかもしれないけれど、listはmutableコンテナだから共変ではないんだって。だから、A <: B（Bが上位型でAはその部分型）のときでもlist[A] <: list[B] にはならないらしいよ。
720: (ﾜｯﾁｮｲ f641-1ngM) 08/12(火)16:10 ID:46uwwH/J0(7/8) AAS
たしかにlistの要素として、その型宣言時の要素型のサブクラスのインスタンスを入れるだけなら特に問題ないはずだとは自分も思うんだよね。
717のcontainer.widgets = [ label(), button(), textbox(), …… ] は、両辺の式の型の間に互換性がない（listは非変なので）点に問題があるということだとすると、container.widget.extend( …… ) とかの書き方にしたら大丈夫なんだろうか。ライブラリのリファレンスとかにはそういう書き方は出てこなかったけど。
721: (ﾜｯﾁｮｲ df01-/C6k) 08/12(火)16:18 ID:PiEjVoIs0(2/3) AAS
>>719
型チェッカーがエラーと報告するならエラーでいいよ
listが共変でないというのは要素型のサブクラスはlistに入れられない話ではない
これはNG
mylist: list[label] = [label]
widgets = mylist
これはOK
widgets = [label]
これもOK
widgets = [label, button, textbox]
722: (ﾜｯﾁｮｲ df01-/C6k) 08/12(火)16:34 ID:PiEjVoIs0(3/3) AAS
OKなはずなのにエラーが出てるのなら最小限の再現コードをpyrightのplaygroundにでも上げてもらったほうがいいかもね
723(1): (ﾜｯﾁｮｲ f641-1ngM) 08/12(火)16:57 ID:46uwwH/J0(8/8) AAS
なるほど、たしかにそれだと警告は出ないね。短い再現コードが出せるようならやってみるけどちょっと難しそうかな。たぶん代入文の右辺について、型チェッカーが（list[widget]と互換性のない）型情報をコード内の別のところから得ちゃっているということなんだろうと思うけど。
724(1): (ﾜｯﾁｮｲ 9a02-QbuV) 08/12(火)19:52 ID:CDoCkaEH0(1) AAS
>>723
型を明記しないとエラーとかってできる？
VBAみたいに
C++のほうが慣れてるから、そのほうがええわ
725: (ﾜｯﾁｮｲ 4e10-1ngM) 08/12(火)21:31 ID:i9fPXIIb0(2/2) AAS
エラーにできるかというのが、静的型付けができていないコードの実行を自動的に抑止できるかという意味なら、Pytnon単体ではムリじゃない？ あくまでも型「注釈」に過ぎないわけだし。でも、型チェッカーの方でそういう設定はあるんじゃないかなぁ。
726(1): (ﾜｯﾁｮｲ cb01-X2XY) 08/12(火)22:31 ID:jU+JMCmR0(1) AAS
>>724
pyrightのstrict modeを試してみるといいと思う
727(2): (ﾍﾞｰｲﾓ MM06-ZDX3) 08/12(火)22:41 ID:nRaft4INM(1) AAS
Pythonの型ヒントって型推論が許されてるけどどこまでそれが効くかはチェッカーの実装依存なんだよね
つまりチェッカーからすると型が不明というのは多くの場合において自身の型推論がショボいことを意味するわけで、
不明だからエラーにするというのは筋が通らないわけよ
せいぜい引数と戻り値に方指定を必須にするくらいだね
728: (ﾜｯﾁｮｲ 7602-7soU) 08/12(火)23:05 ID:DyWlhw4u0(1) AAS
実行時まで型が決まらん、というのまであるしなあ
729: (ﾜｯﾁｮｲ 8a9f-XAuV) 08/12(火)23:06 ID:6cjc6Wvo0(1) AAS
商用プログラム書くならパフォーマンス犠牲になってもランタイムの型チェックがほしい
こんどしれっとtypeguardいれてみようかな
AI支援もあるし猛烈に反対はされなそう
730(1): (ﾜｯﾁｮｲ 9a02-QbuV) 08/13(水)06:35 ID:o5KTBnUB0(1) AAS
>>726
まあでも、
やっぱ、オレみたいなやっぱ要望はたくさんあるんだな
型を明記して欲しいって人
731: (ﾜｯﾁｮｲ 174e-ZDX3) 08/13(水)08:37 ID:+sjCYsF70(1) AAS
>>730
問題は>>727の通り、どこまで明記すれば不明でなくなるのかがPythonの仕様上不明であること
例えば x = f() において、fの戻り値がstrとして型指定されている場合、右辺の式 f() の型は何になるだろう? 左辺で宣言された変数xの型はどうか?
どっちも当然strと思うかもしれないが、これ正確にはどちらも型推論が必要で、なんと型チェッカーの実装依存なんだよね
x: str = typing.cast(str, f())
もし可能な限り明記しようとすればこうなるが、これでもなお実装依存でないとは言えない
732: (ﾜｯﾁｮｲ 231f-1ngM) 08/13(水)09:44 ID:/jTyGuwU0(1) AAS
型付け・型検査の目的は型の不整合の有無を確認することだから、式の型が1つに確定できるならそれが最も分かりやすいとは思うけど、必ずしも1つに確定できなくても（たとえば式の型としてa型、b型、c型の3つの可能性があって、そのいずれについても）型の不整合が生じないことが確認できているのであれば、それで型付け・型検査としての役割は果たしているようにも思うけど。
733: (ﾜｯﾁｮｲ 0754-mJPu) 08/13(水)09:48 ID:rfdqQR7l0(1) AAS
動的型付け言語を静的型付け言語のように取り扱うのが間違い
無管理よりは何かやれることあるだろうという模索の最中だけど、本質的に困難
734: (ﾜｯﾁｮｲ f63f-1ngM) 08/13(水)10:05 ID:IjqUTXVC0(1) AAS
もちろん、静的型付け言語と全面的に同じことができるわけではないけれども、部分的にではあれ良いところを真似することはできるし、邪魔くさいという人は従来どおりのスタイルで書くこともできる。型指定をアノテーションにとどめるというのはそんなに悪いアイデアではないと思うけどなー。
735: (ｱｳｱｳｳｰ Sac7-Kgix) 08/13(水)12:39 ID:U7zZSy+Fa(1) AAS
PyhtonのListが型限定されたら嫌だな
もちろんPyObjectとしては限定されてるが
そういう意味じゃないんだ
736: (ﾜｯﾁｮｲ 4ecf-vKG+) 08/13(水)14:26 ID:52kJFnMW0(1) AAS
>>727
ESLint だと明示的でない any を警告するオプションがあったりする。
型が不明という状況がその型推論がショボいことを意味したりはしないと思うがな。
ただ実用上の問題としては、型ヒントを提供していないモジュールが多いんで
警告が出まくる可能性があること。
737(1): (ﾜｯﾁｮｲ 175f-eMCN) 08/13(水)16:15 ID:jrIykVeu0(1) AAS
自分はpylanceのbasicでちょうどいいくらいだわ
738(1): (ﾜｯﾁｮｲ 3efe-bxVO) 08/13(水)17:18 ID:vtzVqfUP0(1/2) AAS
labelStudioのインストールについて質問してもいいですか？
WindowsパソコンでlabelStudioの最新版をインストールしたのですがコマンドプロンプトでpipコードを入力してもファイルが見つかりませんとなってlabelStudioが起動出来ません。
わかる方いますか？
739(1): (ﾜｯﾁｮｲ 23e7-XAuV) 08/13(水)18:47 ID:God64kkW0(1) AAS
>>738
外部ﾘﾝｸ:labelstud.io
これでためしてみて
Dockerなんて要らないとおもうかもしれないけど
それならまずそんなところで躓かないくらいのオタクになる必要がある
740: (ﾜｯﾁｮｲ 3efe-bxVO) 08/13(水)19:30 ID:vtzVqfUP0(2/2) AAS
>>739
Dockerとはなんぞや？なレベルなんてちんぷんかんぷんです。
ずぶの素人にはインストールすらむずいっす
741: (ﾜｯﾁｮｲ dff2-ChRm) 08/15(金)00:02 ID:UemuT+6G0(1) AAS
pyxが出たよ
…何するツール？
外部ﾘﾝｸ:astral.sh
742: (ﾜｯﾁｮｲ 41f0-/HUD) 08/19(火)07:51 ID:fyqgDdBA0(1) AAS
配列でもdict使えば分かりやすいし変数名で何入るかだいたい分かるやろ
pythonて組込みには使わないし型なんているんか🐼
743: (ﾜｯﾁｮｲ 5957-l4ws) 08/19(火)09:47 ID:ndmX+Emn0(1) AAS
ある程度規模が大きいプログラムでないと型のありがたみは分からないと一般的に言われているのでは。個人的には一応できるだけ型は付けるようにしているけど、可読性の低下に見合うメリットを実感できているかと言われると微妙なところかな。
typingも急速に複雑化したよねー
744: (ﾜｯﾁｮｲ 6130-im2P) 08/19(火)11:31 ID:2nwbx/Cn0(1) AAS
型記述すると可読性が低下すると思っている人と
型記述しないと可読性が低下すると思っている人がいる
745: (ﾜｯﾁｮｲ 4191-Qwzy) 08/19(火)11:53 ID:CS+/mYIY0(1) AAS
使わない理由は手間に見合うかどうかなんだとおもう
コードのノイズになるってんならIDEに型ヒント部分を隠す拡張があればいい
746: (ﾜｯﾁｮｲ dbc5-l4ws) 08/19(火)12:50 ID:AwWeWqwl0(1) AAS
型ヒントを一時的に隠す機能は、たしかにちょっと欲しいかも。というか、もうあるのかもしれないけど。
他人が書いたコードとか、自分が書いたコードでも内容をだいぶ忘れてしまったコードを読むときは型ヒントが大いに助けになるけど、ある程度内容を把握しているコードだと型ヒントがない方が読みやすいってことは結構あるだろうとは思う。
747: (ﾜｯﾁｮｲ 214b-ZBQJ) 08/19(火)17:20 ID:EZlqtCJf0(1) AAS
型ヒントないとメソッドに飛べないでしょ
効率的にコーディングするために必要だよ型ヒントは
748(2): (ﾜｯﾁｮｲ db07-l4ws) 08/20(水)14:50 ID:v4jtEgpO0(1/2) AAS
lambdaの本体に式しか含められないという制限は、どういう考慮からなんだっけ？ 名前あり関数を定義すれば済む話なのでそこまで不便というわけではないのだけれど、lambdaの中にそのまま書けたほうが自然なのになと思うことはちょくちょくある。
749: (ﾌﾞｰｲﾓ MMb3-y2EG) 08/20(水)16:32 ID:qKO8yNcaM(1) AAS
>>748
フレームワークの概念がないのか？
750: (ﾜｯﾁｮｲ f101-SMsS) 08/20(水)17:15 ID:V8h3cYb/0(1) AAS
>>748
式の中にステートメントを入れられないという大前提を覆すとなると影響が大きすぎるしそもそも思想に合わなかったからだと思う
assignment expressionの導入を嫌がってたのにも通じる話
751: (ﾜｯﾁｮｲ dbda-l4ws) 08/20(水)19:37 ID:v4jtEgpO0(2/2) AAS
JavaScriptの関数定義式のイメージで、lambdaを式ではなく文にしたらどうかという前提で考えていたんだが、仮に文にするにしても「値を持つが式文ではない特殊な文」みたいなカテゴリを作るのは大変か。そうするとやむを得ないところかね。
752: (ﾜｯﾁｮｲ 7954-A4gQ) 08/20(水)21:05 ID:z8I7zAVw0(1) AAS
羊のラムの綴りはlamb
一旦lambを書いてからdaを付けると間違わない
753: (ｵｲｺﾗﾐﾈｵ MMa5-1GGU) 08/20(水)22:25 ID:WlXb3anFM(1) AAS
>>737
それでもウザいかな。nodeを自分でインストールする必要ないということで、basedpyrightを使ってみたけど、デフォルトのあまりにうるささに即削除した。
uvとかruffだっけ？のチームが最近始めたやつに少し期待している。
754: (ﾜｯﾁｮｲ 4b8a-Li9w) [Sage] 08/20(水)22:32 ID:ABvMeeh/0(1) AAS
AIをゴリゴリ使って基幹ソフトをRPAとPythonで便利にする仕組みを社内投稿したら、会社でバズってなんかすごいスキルとか言われて困ってる 制作したことに偽りは無いけど、専門部署に呼ばれても知らんし（泣）そもそも制作のモチベーションは現場にあるから専門部署に行ってもしょうがない 現場のおじさんでも作れる時代になった事がエポックメイクな事なのに
755: (ﾜｯﾁｮｲ 9321-/HUD) 08/21(木)04:26 ID:W7b3RP8P0(1/2) AAS
pyrightなんでtypescript使ってるんだろう
node系のやつ重いしなんか不具合出るから嫌い
756: (ﾜｯﾁｮｲ 9321-/HUD) 08/21(木)04:37 ID:W7b3RP8P0(2/2) AAS
pylspがいい？
757: (ﾜｯﾁｮｲ dbc8-VfJp) 08/21(木)10:33 ID:5TY3/WJ10(1) AAS
VSCodeでPylanceを使っているけど、そこまで動作が重いとは感じないかな。警告がいっぱい出て鬱陶しいというのは分かるけど。
758: (ﾗｸｯﾍﾟﾍﾟ MM4b-k6JD) 08/21(木)11:42 ID:sU8D6GG4M(1) AAS
AIを使う業務ソフトならすごいけど
AIを使って作ったソフトって普通のソフトだよね
759: (ﾜｯﾁｮｲ 9379-XJDV) 08/21(木)12:17 ID:xRU3TdBF0(1) AAS
AIを使（って作）ったソフト
760: (ﾜｯﾁｮｲ ab7f-vIW/) 08/21(木)13:08 ID:2lMxcY0H0(1) AAS
AIを使って作った、AIを使う業務ソフトはどうなんだ？
761: (ﾜｯﾁｮｲ 51ab-gibx) 08/21(木)14:36 ID:89YTIbF70(1) AAS
AIを使って作ったAIを使う業務ソフトを作るAIを使って作ったAIを使う業務ソフト
762: (ﾜｯﾁｮｲ 115f-YAjS) 08/21(木)21:05 ID:qlXUTR3c0(1) AAS
AIでなんでも作れるならフォトショップと同等のものをAIに作らせてくれや(´・ω・`)
763(1): (ﾜｯﾁｮｲ c991-fgJ7) 08/23(土)09:41 ID:6fcByJBp0(1) AAS
言語リファレンスで、型引数リストが複合文の最後に入れられているけど、あれって文なのかな？ 暫定的に置いているだけ？
764: (ﾜｯﾁｮｲ c92a-68+F) 08/23(土)19:28 ID:erudRyon0(1) AAS
言語リファレンス中を探し回れってか。
765: (ｱｳｱｳｳｰ Sa45-im2P) 08/23(土)19:47 ID:pcHjlSL+a(1) AAS
BNF
766: (ﾜｯﾁｮｲ db01-JnEk) 08/23(土)22:20 ID:dVERUN7r0(1) AAS
>>763
複合文を構成する要素だから複合文のページで説明してるだけ
式や単純文のところで説明してたらおかしい
767: (ﾜｯﾁｮｲ 8610-ZAtR) 08/24(日)01:08 ID:+j+JozVj0(1/2) AAS
それ自体としては文ではないという点に引っかかりをおぼえていたんだが、式のところに演算子についての記述があるようなものか。
ただ、type文は単純文なので、単純文の構文要素になる場合もある……が、そこはまぁ分かるでしょってことで複合文のところにあるんだろうな。
768: (ﾜｯﾁｮｲ 6a55-hBFX) 08/24(日)02:49 ID:Y0IRLNQN0(1) AAS
Pythonの内包表記やばいな
こんなんでよくperlは読みにくいとか罵れるな
769: (ﾜｯﾁｮｲ 7954-IRdO) 08/24(日)07:50 ID:rMBqpZLF0(1) AAS
慣れるとあれが自然言語のように読めるし、編集せずに先頭から書いていける
770: (ﾜｯﾁｮｲ 8610-ZAtR) 08/24(日)08:22 ID:+j+JozVj0(2/2) AAS
要素を表現する式やinの後が長大になることもしばしばあって、そういう場合はたしかに読みにくいんだけど、基本的にはすごい便利な構文だと思うけどなぁ。発想としては集合の内包表記っぽく書けるようにしようということなんだろうし、やっぱりHaskellは偉大だわ。
たとえばlist内包なら[ （要素を表す式） for （ループ変数・iterable変数） in （iterable） ] で、要素を表す式を書くのにループ変数・iterable変数を使うことができるというだけなので慣れればそんなに難しくないよ。キーワードのforとinが短くて埋没しやすいのが読みにくさを感じる原因なのかもしれない。
771(1): (ﾜｯﾁｮｲ 6aea-hBFX) 08/25(月)00:15 ID:FnDhpDPk0(1/3) AAS
慣れなんかな
巨大な行列が控えてる時の
そんでもなんか人間の認知と違う気がする
772(1): (ﾜｯﾁｮｲ 6a31-uCg5) 08/25(月)01:44 ID:cafSUUHh0(1) AAS
>>771
構文の話をするやつは道具の良し悪しばかりで論じて仕事はさっぱりできない人間
773: (ﾜｯﾁｮｲ adf5-3/RT) 08/25(月)03:06 ID:CxzN3iJP0(1/3) AAS
lambdaもだけど1行に複数の要素が入るととたんに可読性落ちるんで
そこは自制するのがクールという文化(Pythonic)
lambdaはdef、内包表記は複数行にするかforで書きなおす
774(1): (ﾜｯﾁｮｲ 41e8-ZAtR) 08/25(月)09:43 ID:8weJ9FR00(1/2) AAS
lambdaに文は入れられないが、文を含むような場合は名前あり関数として定義する方がわかりやすい……というのが一般論として常に正しいかは相当に疑問だけど。たとえば引数をそのままprintするようなごく単純なコードでも（lambdaにはできないので）名前あり関数にしなければいけないというのはかなりダルい。
Pytnonの文化は文化として尊重するし、実際、概ね妥当なアドバイスになっていることが多いとは思うけど、変えられない言語仕様を擁護するために文化を持ち出すという側面が感じられることもあるかな。
775(1): (ｱｳｱｳｳｰ Sa11-ut8q) 08/25(月)09:52 ID:oTWQEhGga(1/4) AAS
リスト内包が読み難いとか言ってる人は
Generatorとかどうしてるんだろうか
理解出来ないものは目に入らないタイプの人か
776: (ﾜｯﾁｮｲ be5c-ZAtR) 08/25(月)09:56 ID:srlPQ0qE0(1/5) AAS
失礼、print は例として適切じゃないね。単純な代入文に読み替えて。
777: (ｱｳｱｳｳｰ Sa11-ut8q) 08/25(月)09:57 ID:oTWQEhGga(2/4) AAS
lambda x: (print(x), x)[1]
778: (ﾜｯﾁｮｲ be5c-ZAtR) 08/25(月)10:00 ID:srlPQ0qE0(2/5) AAS
ジェネレーターはyieldで書けるから（強引）
ま、慣れるまで読みにくいと感じる人がいるのは分かるけどね。慣れてても「えーっと」ってなることあるし。
779: (ﾜｯﾁｮｲ ddec-hBFX) 08/25(月)10:06 ID:pqTCwzR00(1/2) AAS
>>774
Pythonコミュニティの文化って本質的には「そんなことより仕事しろ」であって、そう理解すると色々納得できるよ
言語を変えるよりしょうもない拘りを捨てた方が早い
780(1): (ｱｳｱｳｳｰ Sa11-ut8q) 08/25(月)10:15 ID:oTWQEhGga(3/4) AAS
代入したければ素直に__setattr__
781: (ﾜｯﾁｮｲ 6a40-hBFX) 08/25(月)11:03 ID:FnDhpDPk0(2/3) AAS
>>772
プログラムで仕事なんかしてねーし
782: (ﾜｯﾁｮｲ 6a40-hBFX) 08/25(月)11:06 ID:FnDhpDPk0(3/3) AAS
>>775
ジェネレータなんて別になんもおかしくなくね？
なんか初心者には難しそうと思った要素出してきたのか？w
783: (ﾜｯﾁｮｲ be5c-ZAtR) 08/25(月)11:11 ID:srlPQ0qE0(3/5) AAS
Pytnonのlambda周りの言語仕様が今さら変わるとも変えたいとも別に思ってはいないけれど、無名関数の本体には文を含められないというのは、言語仕様として中途半端で失敗だったんじゃないかなとは思っている。Pytnonはもう変わらないけれど、新たに設計される言語では（言語設計者が仮に同様に感じたなら）Pytnonの失敗を踏まえてうまく修正するんでしょ。高級言語というのはいわはシンタックスシュガーなんだからそういう点の評価・検証は大事。
ついでに言えば、Pytnonコミュニティの本質が、本当にこういう点をどうでもいいと考えているかもかなり疑問だけどね。少なくとも不満を持っている人がPytnonコミュニティの中にも少なからず居るからこそ、FAQで言い訳じみた説明をしているんじゃないかと思っているが。
式しか含められない中途半端な代物だけど、それである程度は何とかなるのでそれで間に合わせるてくれというのがPytnonコミュニティの文化だということならまぁそうかなと思う。ただ、それが本質的にどうでもいい問題で、そんなことは気にしないのがPytnonコミュニティの文化だと言われると、それは違うんじゃないのってなるかな。
>>780
素直ではないと思うけどw、lambdaでその場で書くというのを優先するならそういうことになっちゃうよね。
784: (ｱｳｱｳｳｰ Sa11-ut8q) 08/25(月)11:34 ID:oTWQEhGga(4/4) AAS
len(hoge) も糞仕様
785: (ﾜｯﾁｮｲ ad11-3/RT) 08/25(月)12:58 ID:CxzN3iJP0(2/3) AAS
最初は面食らうけど特殊メソッドで一般化できてる妙設計
糞だと思うなら代案どうぞ
786: (ｽﾌｯ Sdea-ut8q) 08/25(月)13:12 ID:yimvSMn3d(1) AAS
代案
hoge.__len__()
787: (ﾜｯﾁｮｲ be5c-ZAtR) 08/25(月)13:55 ID:srlPQ0qE0(4/5) AAS
__len__ は今でもあるから、代案ならhoge.lenみたいにメソッド形式で呼べるようにしたいという話なのでは？ Fluent Python のどこかのコラムに書いてあったけど、よく呼ばれるのでパフォーマンスを気にしたとか何とからしいけど。
788: (ﾜｯﾁｮｲ 29e1-M4AR) 08/25(月)15:47 ID:7aQuEbsn0(1) AAS
mapの糞さに比べたらlenなんて可愛いもんだ
789: (ﾜｯﾁｮｲ be15-ZAtR) 08/25(月)16:01 ID:srlPQ0qE0(5/5) AAS
たしかに使う機会は比較的少ないけれど、複数のiterableから並行的に要素を取得していくような場合にはジェネレーター式よりmapの方が便利じゃない？ zipだって特殊なmapなんだから、そんなに邪険に扱わなくても。
一番評判が悪いのは、文字列の連結のjoinだと思う。
790: (ﾜｯﾁｮｲ ade0-3/RT) 08/25(月)17:18 ID:CxzN3iJP0(3/3) AAS
mapレベルならジェネレータ式で書くけど
特殊な操作は明示的にmore-itertoolsつかうんで結局mapなスタイルは残るな
791: (ﾜｯﾁｮｲ 3e01-ChDN) 08/25(月)17:47 ID:d3/9MASU0(1) AAS
内包表記もlambdaも使うのはごく単純な処理でかつside-effect freeの場合だけ
特にlambdaは関数の引数としてインラインで書けるくらいシンプルじゃなければ基本使わない
個人的にはこれが基本原則だと思ってるけどlambdaのside-effectについて明記してるstyle guideないね
792(1): (ﾜｯﾁｮｲ 41e8-ZAtR) 08/25(月)19:04 ID:8weJ9FR00(2/2) AAS
一般論として副作用のない式の方が望ましいのはそうだろうけど、内包表記やlambdaについて、そういう一般論を超えて副作用を避けるべき固有の事情って何かあったっけ。
自分は内包表記では（たまにlambdaでも）結構長いコードになっちゃうことがあるな。別のところに書いて名前で参照する方が分かりやすくなるならもちろんそうするんだけど、結局ここにそのまま書いた方がまだマシかなとなることが結構ある。
793: (ﾜｯﾁｮｲ dd0f-hBFX) 08/25(月)20:04 ID:pqTCwzR00(2/2) AAS
>>792
内包表記や、lambda を引数に取るmapなどの関数は、本来的には実行順序に依存しない
副作用のある式を突っ込んでくるバカを想定するならその前提は破綻し、利用側の既存コードを破壊しないように関数の実装者は注意深く実行順序を維持しなければならなくなる
794: (ﾜｯﾁｮｲ 8610-ZAtR) 08/25(月)21:38 ID:a/zkXuf60(1) AAS
それは一般論の範囲内の話だし、そもそも高階関数の実装者側が注意深く実装すれば副作用の影響を回避できるというものでもないような。どんな副作用かも分からないんだし。
一般論として副作用を持つ式というのは可能な限り避けた方がいいよねというのは前提とした上で、たとえば自分以外がコードに手を入れることはないということが分かっているようなケースでも副作用を避けないといけない具体的な理由みたいなものがあるのかなというのが知りたかったんよ。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 1.371s*