关于列表insert方法和append方法的效率问题

coolsummer2080

多次在相关Python的书籍中看到这样的描述：insert与append相比，计算代价更高。给出的理由是子序列元素不得不在内部移动而为新元素提供空间。
作如下测试：

1. test_ls = ['a', 'c', 'd', 'e']
   
2. print('原列表为：', test_ls)
   
3. print('元素"{}"的地址为:{}。'.format(test_ls[1], id(test_ls[1])))
   
4. test_ls.insert(1, 'b')
   
5. print('在位置1插入新元素后列表为：', test_ls)
   
6. print('元素"{}"的地址为{}。'.format(test_ls[1], id(test_ls[1])))
   
7. print('元素"{}"的地址为{}。'.format(test_ls[2], id(test_ls[2])))

复制代码

输出结果为：
原列表为： ['a', 'c', 'd', 'e']
元素"c"的地址为:47549184。
在位置1插入新元素后列表为： ['a', 'b', 'c', 'd', 'e']
元素"b"的地址为47627872。
元素"c"的地址为47549184。

元素“c”的物理地址并没有变，这说明原位置的元素“c”，并没有移动内存单元，新插入的元素是另外找了个新的单元来存放数据。

那么真像到底是什么呢?是不是写书的作者都是受到C语言的内存管理模式影响呢？

Hoiste

append()方法直接在列表末尾插入元素，而insert()方法是在指定位置插入元素，前者不会移动到列表原有的元素，而后者在使用这个方法的时候就决定了要移动其他元素了，就相当于把原列表重新排列了一下吧。
至于受到C的影响这点我觉得大多数学编程的大佬多少都是会接触或者学习过C语言的，毕竟C语言目前感觉还是影响力比较大的一种语言了。

hrp

test_ls 保存的是元素的地址，插入数据时，数据的地址没变，不代表test_ls中保存的地址顺序没变

1. b = 'b' # id:b
   
2. test_ls = ['a', 'c', 'd', 'e'] # test_ls = [id:a, id:c, id:d, id:e]
   
3. test_ls.insert(1, b) # 1位置及往后的所有保存地址的地址都要移动
   
4. # 如果append则直接添加到末尾，已保存地址的地址，一个都不需要移动
   
5. #  test_ls = [id:a, id:b, id:c, id:d, id:e]

复制代码

coolsummer2080

hrp 发表于 2021-3-21 12:12
test_ls 保存的是元素的地址，插入数据时，数据的地址没变，不代表test_ls中保存的地址顺序没变

感谢回复。你说的可能是对的，目前我还不能完全理解。