Pythonのお勉強 Part75 (729ﾚｽ)
上下前次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
630: (ﾜｯﾁｮｲ 4954-Dra7) 08/09(土)05:22 ID:DWV4fYZO0(1/4)調 AAS
C言語の
char *strcpy(char *dest, const char *src);
dest, srcの順
いまだに逆だろと思う
631: (ﾜｯﾁｮｲ eb49-2ooF) 08/09(土)08:30 ID:U6LvWiSu0(1)調 AAS
give me a chocolate
英語のSVOO形
632: (ﾜｯﾁｮｲ 4954-Dra7) 08/09(土)08:44 ID:DWV4fYZO0(2/4)調 AAS
copyやmoveはそんな文型取らないけどな
コマンドとしてのcopyやmoveはindirect objectを取って、
それはdirect objectに先行するという類推が働くのだろう
ファイルコピーのcopyは送り側が先
ファイル名やディレクトリを並べただけだと、directやindirectの区別が無い
イミディエイトとレジスタとかだと、レジスタがindirectな雰囲気がある
633: (ﾜｯﾁｮｲ 0ff9-kSZg) 08/09(土)09:47 ID:FKLQD73X0(1/2)調 AAS
代入は「は」
比較は「が」
にしよう
日本語って便利
aが0ならaはｂ
634: (ﾜｯﾁｮｲ 7f2a-Jj3s) 08/09(土)10:30 ID:fxyo4EMd0(1)調 AAS
「犬が西向きゃ尾は東」みたいな。
635: (ｵｲｺﾗﾐﾈｵ MMfd-i7aF) 08/09(土)11:26 ID:BSmQSZbLM(1/3)調 AAS
>>629
BASIC言語やFORTRANでも、
x=5
のように書いていた。
元はと言えば、数学の「定義 x≡5」の記法から来たものだと考えられる。
その流れを素直に踏襲すれば、
mov x,5
となる。
636: (ｵｲｺﾗﾐﾈｵ MMfd-i7aF) 08/09(土)11:28 ID:BSmQSZbLM(2/3)調 AAS
定義だけでなく、数学でも「代入」の概念でも同じ記号を使う。
y=a*x^2+b*x+c
に対して、
x=5
を代入するとyの値はどうなるか。
みたいな時の x=5 が、BASICやFORTRANの記法に似ている。
637(1): (ﾜｯﾁｮｲ 4954-Dra7) 08/09(土)11:42 ID:DWV4fYZO0(3/4)調 AAS
数学からの借用だと思うと
x = x + 1
が説明できないので捨てた方がいい
638(1): (ﾜｯﾁｮｲ bbcc-BoCf) 08/09(土)12:02 ID:x+xCY04P0(1)調 AAS
数学の記法云々とか言い出したら、記号の内容がきちんと定義されている限りどんな記号を使っても自由という話にしかならんでしょ。=: とか <=>: とかで右辺に定義される対象を持ってくる記法だって普通にあるんだし。引数の順番とか中置二項演算子の被演算子の順番とかは、本質的に恣意的なものだよ。好みの問題とか、多数派に従っておく方が無難じゃないかとか、その程度の話。
639: (ｵｲｺﾗﾐﾈｵ MMfd-i7aF) 08/09(土)12:49 ID:BSmQSZbLM(3/3)調 AAS
>>638
数学にも、標準記法みたいなものが有る。
高校数学までにそれを教わる。
それによせているのが右翼だ。それに逆らうのが左翼。
640: (ﾜｯﾁｮｲ 0fc3-kSZg) 08/09(土)13:24 ID:FKLQD73X0(2/2)調 AAS
>>637
プログラムってのは数式を解けって意味は無いから
X=X+1 はおかしいっていうほうがおかしい
641(2): (ﾜｯﾁｮｲ 4954-Dra7) 08/09(土)13:52 ID:DWV4fYZO0(4/4)調 AAS
x = x + 1に登場する=は、
数学で言う等号ではないし、定義でもないし、代入でもない
let x as x + 1
くらいの意味だけど、もっと即物的に値の入る箱をイメージして
x ← x + 1
xの中身を+1してxに入れる
としか言いようがない
写像なら何か近いのがありそうだけど、やっぱりずれてる
642: (ﾌﾞｰｲﾓ MMf3-VwDZ) 08/09(土)16:31 ID:S08gCjhtM(1/2)調 AAS
>>641
超初心者だなw
643: (ﾌﾞｰｲﾓ MMf3-VwDZ) 08/09(土)16:32 ID:S08gCjhtM(2/2)調 AAS
>>641
いまだに数学だと教える先生がいるんだろ？
644: (ﾜｯﾁｮｲ 765f-cTHU) 08/10(日)07:20 ID:bJx41RG60(1)調 AAS
右辺値と左辺値
645: (ﾜｯﾁｮｲ 4e10-1ngM) 08/10(日)08:12 ID:5Q2KXoFZ0(1)調 AAS
アドレスとオブジェクトの違い程度ならいいんだけど、C++でムーブがらみでxvalueとか出てくるとピンと来ないんだよね。
646(2): (ﾜｯﾁｮｲ 0754-mJPu) 08/10(日)08:30 ID:rGiN2SBN0(1/10)調 AAS
右辺値と左辺値と言うと余計に判らなくなる
箱 = 値
というシンプルな理解だけで何も困らない
箱には名前があってアドレスを持っていて参照できる
値は箱に入れ終わったら忘れる
647: (ﾜｯﾁｮｲ 232c-1ngM) 08/10(日)09:41 ID:wxvmtlzV0(1/2)調 AAS
コンピューターのアーキテクチャの理解としてはそういう理解の仕方が本質的だと思うけど、Pythonのように、名前（変数）が束縛されているメモリ領域に格納されているのがポインタであって、そのポイント先のオブジェクトが（明示的な参照外しの構文によることなく）名前参照式の評価結果になるような言語では、表れ方がちょっと屈折してくるよね。
「Pytnonでは、変数は、箱のイメージではなくラベル（名札）のイメージで説明する方が適切」というのはしばしば言われる謂ではあるけれども、自分が初心者の人にPytnonを説明するときにそのスタンスでいくかと言われると、ちょっと躊躇するものを感じるかな。
648(1): (ﾜｯﾁｮｲ 7601-AJBo) 08/10(日)09:54 ID:Rqt3voUn0(1/4)調 AAS
>>646
x = “foo”
y = x
は
箱 = 値
箱 = 箱
なのか？
箱 = 箱とは？
みたいな説明が必要になってくる
要は単純な箱と値だけでは説明がつかなくてそれらがどういうコンテキストで使われるかだったり箱から値を取り出して値として使う場合や箱自体を値として使う場合の説明も必要になってくるのでそうシンプルにはならない
649(1): (ﾜｯﾁｮｲ 0754-mJPu) 08/10(日)09:55 ID:rGiN2SBN0(2/10)調 AAS
イコール記号の意味の説明だよ
箱 = 値
と書くと箱に値を入れるという意味になる
箱や値の具体的な内容は違う章
650: (ﾜｯﾁｮｲ 0e46-Fa+d) 08/10(日)10:18 ID:mfIur7J+0(1)調 AAS
ポインタ アドレス渡しってのを明記しない限り
すべて値渡しでいいでしょ
それをいつまでたっても値なのかアドレスなのか毎回混同するやつって
トイレの男女マークはそれでいいのか？っつってるのと被って見える
実にうっとおしい
651: (ﾜｯﾁｮｲ 2357-XAuV) 08/10(日)10:24 ID:w6PHgqLv0(1)調 AAS
箱は大昔のBASICのような基本コピーな言語でしか通用せんよね
dictの中身がなぜ書き換わるのかイメージするには実体を意識したいし矢印かな
652(3): (ﾜｯﾁｮｲ f66d-1ngM) 08/10(日)10:26 ID:wmWYPlFf0(1/9)調 AAS
648の例で言うと、x = "foo"は（C言語レベルでは）名前（変数）xが束縛されているメモリ領域（646風にいえばxという箱）にオブジェクト"foo"のアドレス情報を入れるという形で処理されるし、y = x は（C言語レベルでは）名前（変数）yが束縛されているメモリ領域（646風にいえばyという箱）にオブジェクト"foo"のアドレス情報を入れるという形で処理されることになる。したがって、（C言語レベルでは）646の箱=値という説明で一応一貫した説明ができる。ただし、そこでいう「値（オブジェクト）」はPythonレベルの値（オブジェクト）ではないので、その点に説明・注釈が必要になる。
ラベル（名札）のイメージによる説明というのは、名前x, y が束縛されているメモリ領域を特には観念せず、x, y をオブジェクト"foo"に貼り付けられるラベルとして捉えるということで、Pytnonレベルのみで考えるならこれはこれで1つの説明にはなっていると思う。ただ、listとかのコレクション・コンテナを理解するためには、結局どこかの段階でC言語のポインタの概念を大雑破にでもマスターせざるを得ないと思うんだよね。最初だけポインタの概念を回避してもあまり意味がないように思うので、それが、ラベル（名札）イメージによる説明にあまり乗りたくない個人的な理由。
ちなみに、648の逆パターンの例（x = 2 x = 5 のような再代入のパターン）も同様に考えることができる。
653: (ﾜｯﾁｮｲ 5a4e-a/Iv) 08/10(日)10:32 ID:RtPBWHAF0(1)調 AAS
Pythonは全て参照の値渡し
654: (ﾜｯﾁｮｲ 0754-mJPu) 08/10(日)10:51 ID:rGiN2SBN0(3/10)調 AAS
難しいこと考えなくても、オブジェクト渡しという理解でいい
同じオブジェクトは渡された先でも同じものを指す
内部実装的には同じアドレスを見てるからだけど、
別に別アドレスだったとしても同じ挙動をすればアドレスはどうでもいい
数値とか、対応するアドレスが存在しないものもある
655(2): (ﾜｯﾁｮｲ 7601-AJBo) 08/10(日)10:55 ID:Rqt3voUn0(2/4)調 AAS
>>649
イコール記号の意味だけなら「代入」で十分じゃないの？
代入という概念を知らない人向けの説明なら余計に「箱」が後でどう使われるのかも一緒に説明する必要がある
>>652
y = xではxという箱の中に入ってる値を一端取り出してからそれを複製してyという箱に入れないとダメだよね？
箱から取り出したり複製したりする状況(コンテキスト)も説明できなければ内部知識を知ってる人にだけなんとなく通じる説明方法でしかないと思う
656(1): (ﾜｯﾁｮｲ f66d-1ngM) 08/10(日)11:16 ID:wmWYPlFf0(2/9)調 AAS
>>655
y = x という代入構文において、①右辺のx という名前参照式の評価（名前xが束縛されているメモリ領域に格納されているポインタのポイント先のオブジェクトを得ること）、②それを名前yに代入すること（C言語レベルでは652に書いたとおり、名前yが束縛されるメモリ領域に上記①で得られたオブジェクトのアドレス情報を格納するという形で処理される）という処理が行われるわけだけど、このプロセスに状況（コンテキスト）による違いなんてあるかな？ 状況（コンテキスト）如何に拘らず、上記①②の処理がなされると思っていたんだけど。
まぁ、内部実装についてある程度知識がないと分かりづらいというのはそうだと思う。自分も非常に大雑把な知識しかないしね。
657(1): (ﾍﾞｰｲﾓ MM06-ZDX3) 08/10(日)12:21 ID:rZf5P+kFM(1)調 AAS
Pythonの場合は、numpyの配列のようにPythonオブジェクトの実体すらもPythonの世界の外に存在する物に対する荷札的な役割を果たしているケースがとても多く、
しかも初心者は学習を始めてすぐにそういうイレギュラーなものに触れることになる
なので内部実装を元に説明するのは辛すぎるんだろう
荷札のアナロジーは致命的な矛盾なくだいたいうまく説明できるし実際の動作とそんなにかけ離れてもいない、悪くない説明だと思うよ
658(1): (ﾜｯﾁｮｲ 7a0a-WVpU) 08/10(日)12:27 ID:swuUdv2c0(1/11)調 AAS
>>655
代入という言葉は、数学の変数に値を入れるという意味に引きずられるのでよくないんだよ
659(1): (ﾜｯﾁｮｲ 0754-mJPu) 08/10(日)12:35 ID:rGiN2SBN0(4/10)調 AAS
荷札って箱に付けるものでしょ
そうじゃなくて、実体とは別に存在するコピー可能な何かでないと
そんな都合の良いものは自然界に存在しないので、いいアナロジーも見つからない
660: (ｱｳｱｳｳｰ Sac7-Kgix) 08/10(日)12:43 ID:YgXeJoCWa(1)調 AAS
数学からの借用だと思うと
x = x + 1
は
x[n] = x[n-1] + 1
を意味する
661(1): (ﾜｯﾁｮｲ 7601-AJBo) 08/10(日)12:49 ID:Rqt3voUn0(3/4)調 AAS
>>656
(Pythonの)(y = x という)(代入構文における)(右辺の)x
のxを修飾する部分がコンテキスト
それにその説明だと>>646の言うシンプルな理解からは程遠い気がする
662(1): (ﾜｯﾁｮｲ 7601-AJBo) 08/10(日)12:56 ID:Rqt3voUn0(4/4)調 AAS
>>658
数学の変数に値を入れるという意味に引きずられると何でよくないの？
663: (ﾜｯﾁｮｲ 0754-mJPu) 08/10(日)13:01 ID:rGiN2SBN0(5/10)調 AAS
x = x + 1
の処理毎に加算されていく、というカウンタ動作は、
数列の漸化式というよりは、z^(-1)みたいな離散時間で捉えると動作とよく合う
664(1): (ﾜｯﾁｮｲ 7a0a-WVpU) 08/10(日)13:03 ID:swuUdv2c0(2/11)調 AAS
>>662
数学だと正確にはその例でも左辺と右辺はイコールという意味だ
665: (ﾜｯﾁｮｲ 0754-mJPu) 08/10(日)13:08 ID:rGiN2SBN0(6/10)調 AAS
代入(assign)は割り当てと同じ意味で、何かを別のもので置き換える
y = x + 1
なら何も困らない
x = x + 1
は割り当てではなくて関係式(equation)になって、xは未知数
そして解けない
666(2): (ﾜｯﾁｮｲ f6ce-1ngM) 08/10(日)13:22 ID:wmWYPlFf0(3/9)調 AAS
>>657
コレクション・コンテナを理解するためには、ラベル（名札）のアナロジーによらない方が正確に理解できるし、コレクション・コンテナの重要性を考えるとそれは致命的な弱点だと思うけどね。たとえば、tupleのimmutabilityに関してtupleオブジェクトの要素であるlistの要素に変更があってもそれはtupleのimmutabilityには反しないということを学ぶけど、それは内部実装のイメージがないとわかりにくいと思うよ。
初めのうちから内部実装をベースに理解しようとするのはたしかにムリがあるけれども、ラベル（名札）のアナロジーによる説明は所詮小手先の誤魔化しに過ぎないので、どこかの段階で内部実装に基づく（といっても大したレベルではなく、C言語のポインタの概念の基本を知っていれば足りるレベル）理解に切り替えた方が良いと思うけどね。
>>661
自分は、代入構文の説明としては、結局は箱のイメージで説明するのが（主にラベル（名札）のアナロジーによる説明との比較で）ベターではないかと考えているので、その点では646にも近い立場だけど、それがシンプルに理解できるとは微塵も考えていない。箱に格納されるのはアドレス情報であってそれ自体としてはPytnonのオブジェクトではないし、C言語レベルの内部実装に関する知識に依拠した説明になるからね。647に書いたとおり、本来的には（C言語レベルでは）比較的シンプルなはずのアイデアが、Pytnonでは（仕方のないことではあるけれども）屈折した表れ方になるなぁと思っている。
なお、「コンテキスト（状況）」という語をどういう趣旨で使いたかったのかというのは分かったけど、652に対する批判の文脈でどういう意味合いを持たせたかったのかはよく分からないな。
667: (ﾜｯﾁｮｲ 1af4-ZDX3) 08/10(日)13:25 ID:WyYSCohm0(1/2)調 AAS
>>659
わかってないな、コピーしなくていいんだよ
x = A() # Aの実体をどこかに作成し、荷札xを貼り付ける
y = x # xが貼り付けられている実体に追加で荷札yを貼り付ける
辻褄は合うだろう？
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
このあたりの話かな
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) 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: (ﾜｯﾁｮｲ cb01-X2XY) 08/12(火)22:31 ID:jU+JMCmR0(1)調 AAS
>>724
pyrightのstrict modeを試してみるといいと思う
727: (ﾍﾞｰｲﾓ 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支援もあるし猛烈に反対はされなそう
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 2.288s*