[過去ﾛｸﾞ] Pythonのお勉強 Part68 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
585(1): (ﾜｯﾁｮｲ 8bbb-T9F3) 2022/11/02(水)00:58 ID:I1Z+o8fX0(1) AAS
みんな知ってることだけど、listはmutableでstrはimmutableだからだよ。
これでもう各関数が破壊的かどうかいちいち覚える必要はなくなったね！
586: (ﾌﾞｰｲﾓ MMdd-YnjT) 2022/11/02(水)01:00 ID:WNjxQYpUM(2/2) AAS
listはある程度後ろに確保してるしコストが実際に違ったらそれは明確に合理的な理由でしょ
587: (ﾜｯﾁｮｲ d9f0-5cND) 2022/11/02(水)01:17 ID:jyU6y3CY0(1/6) AAS
>>585
これ
まあそういうものとして覚えるしかないわけだけど
588: (ﾃﾃﾝﾃﾝﾃﾝ MMeb-kKgp) 2022/11/02(水)07:59 ID:cbFKoHcVM(1) AAS
べつに目的の物が作れればどうでもいいんじゃないの？
ミッションクリティカルなモノをコレで作ったりするのかな？
589: (ﾜｯﾁｮｲ 9914-lAaw) 2022/11/02(水)11:06 ID:FQ1wBQnh0(1/2) AAS
listに後ろとか関係なくない？
590(1): (ｱｳｱｳｳｰ Sa9d-mHKc) 2022/11/02(水)11:21 ID:1xZXeW2Ya(1/6) AAS
linkedなリストは関係ないよな
連続したメモリに入ってる配列的なやつはアレだけど
591: (ﾜｯﾁｮｲ 9914-lAaw) 2022/11/02(水)11:39 ID:FQ1wBQnh0(2/2) AAS
>>590
str との違いも結局これだし
592: (ﾌﾞｰｲﾓ MM8d-YnjT) 2022/11/02(水)14:55 ID:VFt43YlcM(1) AAS
pythonのリストはポインタの配列でしょ？
593: (ｱｳｱｳｳｰ Sa9d-mHKc) 2022/11/02(水)18:15 ID:1xZXeW2Ya(2/6) AAS
違います
594(2): (ﾜｯﾁｮｲ d9f0-5cND) 2022/11/02(水)18:27 ID:jyU6y3CY0(2/6) AAS
PyObject*の配列です
PyObject **ob_item; // PyObject*の配列
Py_ssize_t allocated; // アロケートされてる個数
595: (ﾜｯﾁｮｲ d9f0-5cND) 2022/11/02(水)18:28 ID:jyU6y3CY0(3/6) AAS
cpythonなソースは読みやすい
596: (ﾜｯﾁｮｲ d347-gj4s) 2022/11/02(水)18:42 ID:ul/vZuFO0(2/4) AAS
0から255までの数字が入った要素数1000の配列があって、
Cだとunsigned char list[1000];
みたいに宣言してlist[i]で参照するとアドレス計算で値を取ってくるけど、
pythonはどうやってるの?
597(2): (ﾌﾞｰｲﾓ MM8d-YnjT) 2022/11/02(水)18:43 ID:4MCwg8YuM(1/2) AAS
ちょっと調べた限りやっぱりPythonのリストはポインタの配列だと思うんだが違うっていうなら何か教えて
insertの遅さとかで連結リストではないとは思うけど
598: (ﾜｯﾁｮｲ 8b46-g96c) 2022/11/02(水)18:51 ID:wyluLqIy0(1) AAS
>>594が正しい
外部ﾘﾝｸ[h]:github.com
599: (ﾜｯﾁｮｲ d9f0-5cND) 2022/11/02(水)18:55 ID:jyU6y3CY0(4/6) AAS
cpythonのソースはマジで読みやすい
Rubyとかもうぐちゃぐちゃしてて読めねえもん
600: (ﾜｯﾁｮｲ d9f0-5cND) 2022/11/02(水)19:05 ID:jyU6y3CY0(5/6) AAS
実際の配列のサイズはPyObject_VAR_HEADマクロのob_sizeに入ってる
601: (ｱｳｱｳｳｰ Sa9d-mHKc) 2022/11/02(水)19:12 ID:1xZXeW2Ya(3/6) AAS
>>597
別になんでもいいんです
602: (ｱｳｱｳｳｰ Sa9d-5cND) 2022/11/02(水)19:14 ID:5K2+hbiBa(1/3) AAS
答え書かれてるのに全く分かってなくて草
603: (ｱｳｱｳｳｰ Sa9d-mHKc) 2022/11/02(水)19:30 ID:1xZXeW2Ya(4/6) AAS
大学行くと実装と仕様の区別がつくようになるかも？
604: (ﾜｯﾁｮｲ f102-+Dbv) 2022/11/02(水)19:31 ID:l50Y39h10(1/2) AAS
>>594
つまりポインタの配列
605(1): (ﾜｯﾁｮｲ d347-gj4s) 2022/11/02(水)19:31 ID:ul/vZuFO0(3/4) AAS
listにappendすると、ポインタの配列の末尾にポインタが追加される
配列のサイズが変わるので、サイズを増やした配列を作ってコピーしないとできない
筈なのに、idを調べると変わらない
**ob_itemに入ってる値は変わるけど、**ob_item自体のアドレスは変わらない
ということ?
606: (ﾜｯﾁｮｲ f102-+Dbv) 2022/11/02(水)19:33 ID:l50Y39h10(2/2) AAS
組み込みだから作り直した配列にidがコピーされてたり
607: (ﾜｯﾁｮｲ fbe6-Sd0E) 2022/11/02(水)19:36 ID:oCOyjRuB0(1) AAS
VM上は指すオブジェクト変わってないのにid変わったらあかんでしょ
608: (ﾜｯﾁｮｲ 1379-87TA) 2022/11/02(水)19:40 ID:rAnbDRgM0(1/2) AAS
適当にリンクリストあたりかと思ってた
609(2): (ﾜｯﾁｮｲ d347-gj4s) 2022/11/02(水)19:40 ID:ul/vZuFO0(4/4) AAS
appendしても同じオブジェクトという時点で違和感があるんだよな
明らかに別物やん
仮にappendが非破壊で
list = list.append()
とした時にidが変わる方が納得できる
610: (ｱｳｱｳｳｰ Sa9d-5cND) 2022/11/02(水)19:40 ID:5K2+hbiBa(2/3) AAS
>>605
逆だよ
ob_item自体は大きさが変わる時にreallocでアドレスが変わるけど
中身の方はポインタをコピーするだけだから変わらない
611(1): (ｱｳｱｳｳｰ Sa9d-mHKc) 2022/11/02(水)19:42 ID:1xZXeW2Ya(5/6) AAS
>>597
違うって理解できた？
612: (ｱｳｱｳｳｰ Sa9d-5cND) 2022/11/02(水)19:51 ID:5K2+hbiBa(3/3) AAS
>>609
そもそもが全部Cで実装されてるんだからそういうメモリモデルなんだ、という理解で良いと思うよ
613(1): (ﾌﾞｰｲﾓ MM8d-YnjT) 2022/11/02(水)19:53 ID:4MCwg8YuM(2/2) AAS
>>611
あなたは何もわかってないのは理解できました
614: (ｱｳｱｳｳｰ Sa9d-mHKc) 2022/11/02(水)19:57 ID:1xZXeW2Ya(6/6) AAS
>>613
わかんない？
違うよ
どんどん主張が後退するんじゃねえかなという期待の下、繰り返すけど
上下前次1-新書関写板覧索設栞歴
あと 388 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.013s