Pythonのお勉強 Part75

2025/04/04(金) 01:47:04.18

!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/06(水) 19:39:33.54

>>583
>>584

2025/08/06(水) 21:25:50.50

型ヒント使うと関数シグネチャも複数行になりがちだけど
それも見た目の工夫であってオフサイドルールちゃうからね
インデントは主体じゃなくブロックを表現するための手段

2025/08/06(水) 21:32:09.86

if a == 0 and
　 b == 1:
を書きたい

2025/08/06(水) 21:47:05.00

>>587
汎用的でないそこ固有の評価ってんなら
直前にnested function書いて意地でも複数行にしない
名前がついてわかりやすくなる

2025/08/06(水) 21:51:47.17

if (
　a == 0 and
　b == 1
):

みたいなのじゃあかんの？

2025/08/06(水) 21:55:07.88

C言語だと
if ( (a == 0) and
　　 (b == 1) ) {
みたいなのはごく普通なのでいいんだけど
自明な括弧は要らんやろという流儀なのに

2025/08/06(水) 22:30:13.39

and (笑)

2025/08/06(水) 22:47:28.22

だめなの？

2025/08/06(水) 22:56:14.77

&&だろという揚げ足取りだよ
なんか偉い人だと思われている

2025/08/07(木) 09:12:03.20

==も＆＆もキモイ

何のためのコンパイラだよ？
＝　＆で事足りるってのに、アホ化していく

2025/08/07(木) 09:16:09.44

こうしてまた各人の好みの押し付け合いが始まる

2025/08/07(木) 09:43:25.61

>>594
> ＝　＆で事足りるってのに、アホ化していく

どういう意味?
&& を &、== を = で事足らすと、既存の & や = と区別つかないと思うけど。

2025/08/07(木) 10:20:37.40

iso646.hにしれっと==も紛れ込ませてたらよかった

2025/08/07(木) 17:42:40.07

>>596
人間はいとも簡単に区別付けられるんだぞ？
コンパイラが区別不可能なわけがないんだよ

2025/08/07(木) 17:53:29.93

>>598
=や&で事足りて簡単に区別できるというなら
`x = y = z`のイコールは`==`の意味か`=`の意味か区別してみて？
`x & y`のアンパサンドは`&&`の意味か`&`の意味か区別してみて？

2025/08/07(木) 18:14:18.13

アホなやつ

2025/08/07(木) 18:40:01.88

ブーメランw

2025/08/07(木) 19:29:59.52

:= を使う言語は何なんだろう

2025/08/07(木) 20:31:57.45

プロローグだっけ

2025/08/07(木) 20:38:51.69

なぜ := にしたのだろうね。= で == と区別できるから充分だろうに。

>>> if a = 3:
　File "<stdin>", line 1
　　if a = 3:
　　　 ^^^^^
SyntaxError: invalid syntax. Maybe you meant '==' or ':=' instead of '='?

2025/08/07(木) 20:49:39.81

:= 代入
== 比較
= 比較(大文字と小文字を区別しない)

そんなどうでもいいことの為に演算子作るな

2025/08/07(木) 21:23:26.56

等号記号の意味からすると
letつけたり:=とする方が自然なのはわかる

2025/08/07(木) 21:42:01.86

数学に:=と=:があって、そこから借りてきたんだろうけど、
定義だから代入とは意味が違うんだよな

2025/08/07(木) 21:54:14.51

>>605
> = 比較(大文字と小文字を区別しない)

どゆこと?

>>> 'abc' = 'ABC'
　File "<stdin>", line 1
　　'abc' = 'ABC'
　　^^^^^
SyntaxError: cannot assign to literal here. Maybe you meant '==' instead of '='?

2025/08/07(木) 22:59:09.20

a <- 3
b <- 4
c <- a + b

if ? c = 7
　c <- c + 1
else
　c <- c + 2

こんな風な言語があるけどどうだろう

2025/08/07(木) 23:07:34.65

抽象化しようとするから意味がおかしくなる
レジスタやメモリへの書き込みなんだから矢印でいいのに

2025/08/07(木) 23:15:15.05

レジスタやメモリの書き込みにしても
MOV A, 1
という記法もあれば
MOV 1, A
という記法もあるので、
言語デザイナーは罪深いというかセンスがおかしいというか

2025/08/08(金) 10:12:55.93

>>609
それ＜－ってのを＝に描き直したって全く間違うことは無いのにねぇ

2025/08/08(金) 10:18:16.23

発端は
C=C+1

これを見た馬鹿が、CとC+1はイコールじゃないぞ！って発狂したことだと思う
そんな馬鹿は放っとけばよかったのだ

2025/08/08(金) 10:39:41.08

今から言語作るなら<-はお勧めしない
a <- 1
a < -1
が紛らわしい

2025/08/08(金) 10:40:20.59

>>612
代入式と比較式が同じコンテキストで使われないと勘違いしてるからそう思うだけ
もう少し視野を広げたほうがいい

2025/08/08(金) 11:22:59.63

c << c + 1

2025/08/08(金) 11:51:57.43

等号・相当性判定を=にして、代入には別の記号を与えるというのが分かりやすいと思うんだけど、いかんせん普通の命令型言語では代入が多用されるので、出来るだけ短い記号をあてたいというモーメントが働くんだろうね。
関数型言語では代入が少ないのでletを付けてもそんなに面倒ではないというのよくできていると思うわ。命令型言語ならPascal方式が分かりやすさという点では一番だと思うんだけど、実際に代入のたびに:=と書けと言われたらたしかに面倒だろうなぁとは思う。

2025/08/08(金) 14:14:34.86

cout << c + 1;

2025/08/08(金) 17:44:16.45

>>611
デファクトスタンダードは、Z80、x86系、AMD64系すべてで、
mov A,imm
だが、
GNUは、
mov imm,A
を使っている。
これも、左翼思想だと思う。
デファクトスタンダードと逆のことを無料で使わせる事で、
社会を逆回転させようとする。

2025/08/08(金) 17:49:55.09

(1)デファクトスタンダード(COPYRIGHT)
・企業で作ったソフトウェアは、コピー禁止にして有料にして売ろう。
・書き方は、数学の dst = src に近くして、mov dst,src だ。
・同様にメモリーコピーも、memcpy(dst,src,size)だ。
(2)左翼(GNU、FSF、COPYLEFT、GPL ; 天邪鬼)
・全部ソース公開にして無料にしてやる。地球上のあらゆるソースを無理やりにでも公開させてやる。
・書き方は、デファクトスタンダードの逆にして、mov src,dst だ。
・STLでは、メモリーコピーも、std::copy(src_begin, src_end, dst_begin)でsrcとdstの順序を逆にしてやる。

2025/08/08(金) 19:13:01.77

順序に意味をもたせるのが間違い
mov(from=val, to=regA)
mov(to=regA, from=val)
どっちで書いてもok

2025/08/08(金) 20:34:04.88

>>621
長すぎるわ。

2025/08/08(金) 20:47:21.31

ニーモニックが短いのは自動入力とか無かった頃の名残だな
そして最新マイコンでもやっぱり短くて暗号みたいなニーモニックになってる
覚えられない

2025/08/08(金) 21:38:15.47

物理的に１行80文字のパンチカードまで遡りそう

2025/08/09(土) 00:09:42.89

rax=5 の意味を書くのを、以下のどれが一番分かり易いか、楽か、と言う意味だ:
1. mov rax,5
2. mov 5,rax
3. mov(from=5, to=rax)
順序からして1が一番分かり易いだろう。
それは、左翼たちは 2 がいいと主張するのだ。

2025/08/09(土) 00:10:33.01

誤: それは、左翼たちは 2 がいいと主張するのだ。
正: それを、左翼たちは 2 がいいと主張するのだ。

2025/08/09(土) 00:20:02.12

別に積極的にどれかを支持するつもりはないのだけれど、フラットに見たら分かりやすいのは3で、書くのが楽なのが1・2じゃない？
「左翼」「右翼」という言葉をむやみに使いたがるやつは頭が悪いんだなというのが一番の感想なんだけどね。

2025/08/09(土) 00:26:20.38

>>627
敢えて大多数の人の習慣と逆をやろうとするのが左翼なんだよ。

2025/08/09(土) 02:27:43.20

> 順序からして1が一番分かり易いだろう。
ここがウケるポイント
オレも慣れ親しんでるのは1だけどな

2025/08/09(土) 05:22:53.28

C言語の
char *strcpy(char *dest, const char *src);

dest, srcの順
いまだに逆だろと思う

2025/08/09(土) 08:30:47.32

give me a chocolate
英語のSVOO形

2025/08/09(土) 08:44:00.58

copyやmoveはそんな文型取らないけどな

コマンドとしてのcopyやmoveはindirect objectを取って、
それはdirect objectに先行するという類推が働くのだろう

ファイルコピーのcopyは送り側が先
ファイル名やディレクトリを並べただけだと、directやindirectの区別が無い
イミディエイトとレジスタとかだと、レジスタがindirectな雰囲気がある

2025/08/09(土) 09:47:09.17

代入は「は」
比較は「が」
にしよう
日本語って便利

aが0ならaはｂ

2025/08/09(土) 10:30:12.46

「犬が西向きゃ尾は東」みたいな。

2025/08/09(土) 11:26:29.39

>>629
BASIC言語やFORTRANでも、
x=5
のように書いていた。
元はと言えば、数学の「定義 x≡5」の記法から来たものだと考えられる。
その流れを素直に踏襲すれば、
mov x,5
となる。

2025/08/09(土) 11:28:33.54

定義だけでなく、数学でも「代入」の概念でも同じ記号を使う。
y=a*x^2+b*x+c
に対して、
x=5
を代入するとyの値はどうなるか。
みたいな時の x=5 が、BASICやFORTRANの記法に似ている。

2025/08/09(土) 11:42:18.72

数学からの借用だと思うと
x = x + 1
が説明できないので捨てた方がいい

2025/08/09(土) 12:02:44.93

数学の記法云々とか言い出したら、記号の内容がきちんと定義されている限りどんな記号を使っても自由という話にしかならんでしょ。=: とか　<=>: とかで右辺に定義される対象を持ってくる記法だって普通にあるんだし。引数の順番とか中置二項演算子の被演算子の順番とかは、本質的に恣意的なものだよ。好みの問題とか、多数派に従っておく方が無難じゃないかとか、その程度の話。

2025/08/09(土) 12:49:26.30

>>638
数学にも、標準記法みたいなものが有る。
高校数学までにそれを教わる。
それによせているのが右翼だ。それに逆らうのが左翼。

2025/08/09(土) 13:24:44.86

>>637
プログラムってのは数式を解けって意味は無いから
X=X+1　はおかしいっていうほうがおかしい

2025/08/09(土) 13:52:36.69

x = x + 1に登場する=は、
数学で言う等号ではないし、定義でもないし、代入でもない
let x as x + 1
くらいの意味だけど、もっと即物的に値の入る箱をイメージして
x ← x + 1
xの中身を+1してxに入れる
としか言いようがない

写像なら何か近いのがありそうだけど、やっぱりずれてる

2025/08/09(土) 16:31:26.10

>>641
超初心者だなw

2025/08/09(土) 16:32:27.62

>>641
いまだに数学だと教える先生がいるんだろ？

2025/08/10(日) 07:20:54.61

右辺値と左辺値

2025/08/10(日) 08:12:33.70

アドレスとオブジェクトの違い程度ならいいんだけど、C++でムーブがらみでxvalueとか出てくるとピンと来ないんだよね。

2025/08/10(日) 08:30:50.47

右辺値と左辺値と言うと余計に判らなくなる

箱 = 値

というシンプルな理解だけで何も困らない
箱には名前があってアドレスを持っていて参照できる
値は箱に入れ終わったら忘れる

2025/08/10(日) 09:41:25.77

コンピューターのアーキテクチャの理解としてはそういう理解の仕方が本質的だと思うけど、Pythonのように、名前（変数）が束縛されているメモリ領域に格納されているのがポインタであって、そのポイント先のオブジェクトが（明示的な参照外しの構文によることなく）名前参照式の評価結果になるような言語では、表れ方がちょっと屈折してくるよね。
「Pytnonでは、変数は、箱のイメージではなくラベル（名札）のイメージで説明する方が適切」というのはしばしば言われる謂ではあるけれども、自分が初心者の人にPytnonを説明するときにそのスタンスでいくかと言われると、ちょっと躊躇するものを感じるかな。

2025/08/10(日) 09:54:58.08

>>646
x = “foo”
y = x
は
箱 = 値
箱 = 箱
なのか？
箱 = 箱とは？
みたいな説明が必要になってくる

要は単純な箱と値だけでは説明がつかなくてそれらがどういうコンテキストで使われるかだったり箱から値を取り出して値として使う場合や箱自体を値として使う場合の説明も必要になってくるのでそうシンプルにはならない

2025/08/10(日) 09:55:11.34

イコール記号の意味の説明だよ
箱 = 値
と書くと箱に値を入れるという意味になる

箱や値の具体的な内容は違う章

2025/08/10(日) 10:18:31.58

ポインタ　アドレス渡しってのを明記しない限り
すべて値渡しでいいでしょ

それをいつまでたっても値なのかアドレスなのか毎回混同するやつって
トイレの男女マークはそれでいいのか？っつってるのと被って見える
実にうっとおしい

2025/08/10(日) 10:24:29.45

箱は大昔のBASICのような基本コピーな言語でしか通用せんよね
dictの中身がなぜ書き換わるのかイメージするには実体を意識したいし矢印かな

2025/08/10(日) 10:26:55.01

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 のような再代入のパターン）も同様に考えることができる。

2025/08/10(日) 10:32:52.85

Pythonは全て参照の値渡し

2025/08/10(日) 10:51:05.32

難しいこと考えなくても、オブジェクト渡しという理解でいい

同じオブジェクトは渡された先でも同じものを指す
内部実装的には同じアドレスを見てるからだけど、
別に別アドレスだったとしても同じ挙動をすればアドレスはどうでもいい
数値とか、対応するアドレスが存在しないものもある

2025/08/10(日) 10:55:58.34

>>649
イコール記号の意味だけなら「代入」で十分じゃないの？
代入という概念を知らない人向けの説明なら余計に「箱」が後でどう使われるのかも一緒に説明する必要がある

>>652
y = xではxという箱の中に入ってる値を一端取り出してからそれを複製してyという箱に入れないとダメだよね？
箱から取り出したり複製したりする状況(コンテキスト)も説明できなければ内部知識を知ってる人にだけなんとなく通じる説明方法でしかないと思う

2025/08/10(日) 11:16:35.60

>>655
y = x という代入構文において、①右辺のx という名前参照式の評価（名前xが束縛されているメモリ領域に格納されているポインタのポイント先のオブジェクトを得ること）、②それを名前yに代入すること（C言語レベルでは652に書いたとおり、名前yが束縛されるメモリ領域に上記①で得られたオブジェクトのアドレス情報を格納するという形で処理される）という処理が行われるわけだけど、このプロセスに状況（コンテキスト）による違いなんてあるかな？　状況（コンテキスト）如何に拘らず、上記①②の処理がなされると思っていたんだけど。

まぁ、内部実装についてある程度知識がないと分かりづらいというのはそうだと思う。自分も非常に大雑把な知識しかないしね。

2025/08/10(日) 12:21:16.95

Pythonの場合は、numpyの配列のようにPythonオブジェクトの実体すらもPythonの世界の外に存在する物に対する荷札的な役割を果たしているケースがとても多く、
しかも初心者は学習を始めてすぐにそういうイレギュラーなものに触れることになる
なので内部実装を元に説明するのは辛すぎるんだろう
荷札のアナロジーは致命的な矛盾なくだいたいうまく説明できるし実際の動作とそんなにかけ離れてもいない、悪くない説明だと思うよ

2025/08/10(日) 12:27:59.80

>>655
代入という言葉は、数学の変数に値を入れるという意味に引きずられるのでよくないんだよ

2025/08/10(日) 12:35:23.78

荷札って箱に付けるものでしょ
そうじゃなくて、実体とは別に存在するコピー可能な何かでないと
そんな都合の良いものは自然界に存在しないので、いいアナロジーも見つからない

2025/08/10(日) 12:43:40.03

数学からの借用だと思うと
x = x + 1
は
x[n] = x[n-1] + 1
を意味する

2025/08/10(日) 12:49:59.24

>>656
(Pythonの)(y = x という)(代入構文における)(右辺の)x
のxを修飾する部分がコンテキスト

それにその説明だと>>646の言うシンプルな理解からは程遠い気がする

2025/08/10(日) 12:56:31.19

>>658
数学の変数に値を入れるという意味に引きずられると何でよくないの？

2025/08/10(日) 13:01:51.64

x = x + 1
の処理毎に加算されていく、というカウンタ動作は、
数列の漸化式というよりは、z^(-1)みたいな離散時間で捉えると動作とよく合う

2025/08/10(日) 13:03:29.02

>>662
数学だと正確にはその例でも左辺と右辺はイコールという意味だ

2025/08/10(日) 13:08:38.63

代入(assign)は割り当てと同じ意味で、何かを別のもので置き換える
y = x + 1
なら何も困らない
x = x + 1
は割り当てではなくて関係式(equation)になって、xは未知数
そして解けない

2025/08/10(日) 13:22:53.03

>>657
コレクション・コンテナを理解するためには、ラベル（名札）のアナロジーによらない方が正確に理解できるし、コレクション・コンテナの重要性を考えるとそれは致命的な弱点だと思うけどね。たとえば、tupleのimmutabilityに関してtupleオブジェクトの要素であるlistの要素に変更があってもそれはtupleのimmutabilityには反しないということを学ぶけど、それは内部実装のイメージがないとわかりにくいと思うよ。
初めのうちから内部実装をベースに理解しようとするのはたしかにムリがあるけれども、ラベル（名札）のアナロジーによる説明は所詮小手先の誤魔化しに過ぎないので、どこかの段階で内部実装に基づく（といっても大したレベルではなく、C言語のポインタの概念の基本を知っていれば足りるレベル）理解に切り替えた方が良いと思うけどね。

>>661
自分は、代入構文の説明としては、結局は箱のイメージで説明するのが（主にラベル（名札）のアナロジーによる説明との比較で）ベターではないかと考えているので、その点では646にも近い立場だけど、それがシンプルに理解できるとは微塵も考えていない。箱に格納されるのはアドレス情報であってそれ自体としてはPytnonのオブジェクトではないし、C言語レベルの内部実装に関する知識に依拠した説明になるからね。647に書いたとおり、本来的には（C言語レベルでは）比較的シンプルなはずのアイデアが、Pytnonでは（仕方のないことではあるけれども）屈折した表れ方になるなぁと思っている。
なお、「コンテキスト（状況）」という語をどういう趣旨で使いたかったのかというのは分かったけど、652に対する批判の文脈でどういう意味合いを持たせたかったのかはよく分からないな。

2025/08/10(日) 13:25:39.30

>>659
わかってないな、コピーしなくていいんだよ
x = A() # Aの実体をどこかに作成し、荷札xを貼り付ける
y = x # xが貼り付けられている実体に追加で荷札yを貼り付ける
辻褄は合うだろう？

2025/08/10(日) 13:45:18.60

荷札という名称が悪すぎるわw

実体の所有者(複数可)が誰か判るような管理リスト、みたいなイメージ
実際にはリストじゃないからこの時点で乖離があるけど
登記簿とか株券の裏を複数所有可能にした的な
所有してる訳でもないのでズレる

なんで「参照」の一言を参照使わずに説明するのがこんなに困難なのか

2025/08/10(日) 14:04:35.99

>>666
t = (x, y)
u = t
これは、荷札xの付いた実体に対して荷札t[0]を、荷札yの実体に対して同様に荷札t[1]を貼り付ける、
同時に、荷札t[0]とt[1]を管理するために”t[0], t[1]”と書かれた台帳を作成し、その台帳に荷札uを付けると解釈すればよい
これは参照の向きを逆に捉えて参照される側が参照元を記憶していると考えているだけなので、基本的にはこのような説明で矛盾は生じない
荷札名から実体を探すのが大変だという問題は残るけどね

2025/08/10(日) 14:29:10.70

仮にそれをそのまま実装に反映させるなら、Pytnonオブジェクトに（被参照カウント数に加えて）参照元のリストも持たせるってことでしょ。
そうではなく、単に解釈モデルに過ぎないってことなら、内部実装がそうなっているわけでもないのに、あえてそんな不自然な解釈モデルを作ってまで荷札（ラベル・名札）のアナロジーに拘る意味ってあるのかな？　たとえばそれで、（666でちょっと触れた）tupleの要素であるlistの要素を変更してもtupleのimmutabilityに反しないことの説明がしやすくなったりする？

2025/08/10(日) 15:10:39.92

>>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」なら←は代入ですと言ってもしっくりくるのかな？

2025/08/10(日) 15:49:18.97

>>671
だから:=にしているプログラミング言語もある

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

仕事では「設定」などと呼ぶ。英語でもsetと呼んでいる。

2025/08/10(日) 15:53:58.39

>>666
>652に対する批判の文脈でどういう意味合いを持たせたかったのかはよく分からないな

>>648に書いてるのと同じなんだけど箱を箱のまま入れ物として取り扱う状況と箱を箱の中身が示す値として取り扱う状況の説明なくそれらを無意識に使い分けながら「一貫した説明ができる」と言ってるのを自覚して欲しかったとでも言えばいいだろうか

2025/08/10(日) 15:57:29.66

代入という訳語の気が利きすぎてるんだよな
assignのニュアンスそのままなら代入は出てこない
単に関連付けをしてるだけ
代わりに入れるという何か動きを持った訳語にしたせいで、逆に理解を阻害する

2025/08/10(日) 16:00:48.44

>>672
setには、ある既存の構造を正しく整った状態へと変えるというニュアンスがある
単なる変数の代入は変数の中身をまるっと置き換えているだけで既存の構造を変化させているわけではないし、
新しい値もそれが正しく整ったものとは限らず、ごく一時的なものだったりする
なのでより直接的なassignが用いられる

2025/08/10(日) 16:14:57.79

>>675
Pythonの話なら私は知らない。

2025/08/10(日) 16:46:12.05

Pytnonの言語仕様として「代入文」という名称で規定されているんだから、ひとまずこのスレで「代入」と呼ぶことには何の問題もないと思うけどね。それが数学における代入概念とは意味が違うから別の呼び方をすべきだというのは1つの意見としては傾聴に値すると思うけど、それはまた別の話でしょ。

>>673
それは661でコンテキスト（状況）として挙げられた要素に対応する違いであるか甚だ疑問だし、そもそも「箱を箱の中身が示す値として取り扱う」というようなふわっとした理解だから混乱するのでは。
大前提として、①名前と②名前が束縛されるメモリ領域（＝箱）とは区別される概念だけどこれはいい？　それから、②名前が束縛されるメモリ領域（＝箱）と③そこに格納されている実体（オブジェクト・値）も区別される概念だけどこっちはいいよね。たぶん、①②の区別が曖昧だから「箱を箱の中身が示す値として取り扱う」というような表現が出てくるんだと思うけど。
注意すべきは「変数」という用語の多義性で、この語は上記①～③のいずれを指すか曖昧なまま使われがち。かつそういう曖昧な認識のまま「変数＝箱」という説明がされがちなので混乱が起きるんだと思うけどね。なお、そういう観点からいうと、646の「箱＝値」という表記の仕方も（直感的にはわかりやすいけれども）こういう曖昧な理解を助長する弊害はあるんだろう。
上記のような概念的な区別がきちんとできている限り、コンテキスト（状況）如何で変わるような話ではないということは理解しやすいと思うけどどうかな（あるいは、必要なのは概念的な区別であって、コンテキスト（状況）の場合分けではないという言い方をしても良い）。

2025/08/10(日) 17:03:01.76

箱は伝統的なプログラミング入門書が使うわかりにくい例えだしな

それより丸数字の使用が気になるぞ

2025/08/10(日) 17:11:26.30

ドキュメンテーションのない仕事をしているのがはっきりとわかるよなあ

2025/08/10(日) 17:15:06.72

メモリ領域を箱に例えるのはコンピューターのアーキテクチャーに忠実な良い例えだと思うけどね。Pytnonみたいな言語ではC言語レベルに還元しないと正確な理解に到達できないという憾みはあるが、それでもラベル（名札・荷札）のアナロジーのような曖昧なイメージに頼るよりよほど良いと思うよ。

ところで、丸数字って今でも読みづらく化けたりする？　5chみたいなところで使う分には、もう、そんなに気にしなくても良い時代かなと思っていたんだが。

2025/08/10(日) 17:20:18.25

一番気になるのは改行しないことだな

2025/08/10(日) 18:04:10.77

>>677
>>652から引用すると「y = x は（C言語レベルでは）名前（変数）yが束縛されているメモリ領域（646風にいえばyという箱）にオブジェクト"foo"のアドレス情報を入れるという形で処理されることになる。」

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

同じxでも直前の`x=“foo”`のxは箱のまま入れ物として取り扱われていたが
`y = x`のxは箱の中身が指し示す値として取り扱われている
その違いを生むのがxが評価されるコンテキストの違い

2025/08/10(日) 18:34:46.42

アセンブラのニーモニックが辞書を片手に見るか、覚えていないといけないのをわかりやすく表現しただけのものをマシン語の並び順すら知らずにこねくり回した説明をしているのは滑稽

2025/08/10(日) 18:45:58.86

>>682
CPUのレジスタがメモリのような連続した長いものでないため、コンピューターではレジスタで収まるものとそうでないものの区別がある。

コンピューターそのものがCPUとメモリという別のものを組み合わせているから、メモリへの参照なのかどうかは曖昧にしたまま進化しただけ。