我有一个他们可能或可能不会被任意嵌套的项目列表.我想替换其中一个列表的元素.无论哪种方式(嵌套或不嵌套),我都将元素的索引位置存储在另一个列表中.
这是一个嵌套列表示例,我想用其他东西替换’xyz’,比如说123.我在loc中存储了’xyz’的位置：
find='xyz'
replace=123
nested=[['abc',1],['xyz',2]]
print(loc) # [1,0]
使用loc如何用’xyz’代替123？
这是一个unnested示例,我想做同样的替换：
unnested=['abc','xyz']
print(loc) # [1]
如果loc只有一个元素,那么你可以简单地做：
*nest,element=loc
if not nest:
unnested[element]=replace
else: pass # need help with this part
有足够的灵活性来处理这两种情况吗？
解决方法:
这和其他答案一样,只是以功能方式走这条路：
reduce(getitem, loc[:-1], nested)[loc[-1]] = replace
在Python 3中,您需要从functools导入reduce. getitem来自操作符模块.如果您只有列表,则可以使用list .__ getitem__.
说明：reduce以嵌套开头,并用locitem(thecurrentvalue,i)替换为loc [： –  1]中的每个值i.因此,例如,如果loc是[2,4,1,3],那么你得到getitem(getitem(getitem(嵌套,2),4),1).这与嵌套[2] [4] [1]相同.
标签：python,replace
来源： https://codeday.me/bug/20190823/1702663.html

num=[‘pineapple’,‘grape’,‘pear’]

num[0:2]=“asd” 因为字符串会迭代所以asd会拆开一个字符一个字符的取替换num[0:2] 中的num[0],num[1]并把d插入到num[1]后边的num[2]位置，（其实就是如果多的话就一直向后插入）后从num[2]开始的后边的元素就会一直等到插入之后再加到后面

List是什么？
List顾名思义就是列表，那么它具体描述是什么呢？
列表是一个线性的集合，它允许用户在任何位置插入、删除、访问和替换元素。在Python中list是保留字，List中的每个元素都有自己的编号，很像C、C++、java中的数组，但是List更强大。列表主要有以下几个特点：
列表中元素顺序是有序的。比如，你将1,2,3一次存入列表，那个列表中元素顺序一定是1,2,3，而不会是其他的。
列表长度不确定。不同于C/C++里的数组，列表长度不确定，在使用列表时不需要提前声明长度。
列表中存储的元素类型可以不唯一。可以将任何东西加入列表中，其中元素之间可以没有任何关系。
列表中可以有重复元素。
List简单使用
1. 列表创建
创建一个列表，只要把逗号分隔的不同的数据项使用方括号括起来即可。如下所示：
此外，如果创建一些常用的数列等列表，可采取以下pythonic的方法快速创建列表：
2. 列表访问
列表访问和其他数组访问差不多，常用索引。但是python列表可以切片，可以取指定索引区间内的元素。
3. 操作列表的函数
len(list)：列表元素个数
max(list)：返回列表元素最大值
min(list)：返回列表元素最小值
list(seq)：将元组转换为列表
del：删除列表，释放内存空间
例子：
3. 列表类型定义的函数
list.append(obj)：在列表末尾添加新的对象
list.count(obj)：统计某个元素在列表中出现的次数
list.extend(seq)：在列表末尾一次性追加另一个序列中的多个值
list.index(obj)：从列表中找出某个值第一个匹配项的索引位置
list.insert(index, obj)：将对象插入列表
list.pop(obj=list[-1])：移除列表中的一个元素(默认最后一个元素)，并返回
list.remove(obj)：移除列表中某个值的第一个匹配项
list.reverse()：反向列表中元素
list.sort([func])：对原列表进行排序
例子：
list一些常见函数的时间复杂度
常见函数的时间复杂度
【附加阅读】
底层实现机制
List对象是用c结构来实现，由一个保存元素的指针数组和预先分配的内存总容量构成。分离式结构，两者之间用一个元素建立一个链接，连在一起。能够根据元素的数量自动的扩充或者缩小list的内存大小。
要在内存中给集合开辟一块区域，总得先确定大小(容量)，不然如何开辟？另外，确定区域后，还要知道当前已经占用了几个元素(元素个数)，一旦溢出，就需要重新申请空间。要表达这种结构，有两种实现方式。一种是把头信息和元素串到一起，形成一个元素个数+2的表。另一种就是把头信息和元素分开放，两者之间用一个元素建立一个链接，连在一起。
存储表信息的单元与元素存储区以连续的方式安排在一块存储区里，两部分数据的整体形成一个完整的顺序表对象。一体式结构整体性强，易于管理。但是由于数据元素存储区域是表对象的一部分，顺序表创建后，元素存储区就固定了。
分离式结构中表对象里只保存与整个表有关的信息(即容量和元素个数)，实际数据元素存放在另一个独立的元素存储区里，通过链接与基本表对象关联。一旦表需要扩充，对于一体式结构来说，就要重新申请一块更大的空内存区域，将所有元素放入其中，再清空旧的内存区域。对于分离式结构来说，则需要将链接地址更新一下，顺序表对象是不变的。
List的扩充采取两种策略，每次扩充增加固定数目的存储位置，这种策略可称为线性增长，节省空间，但是扩充操作频繁，操作次数多。每次扩充容量加倍，以空间换时间。从实现上来讲，在python中创建空ist时，会申请一个8个元素大小的内存区域。以后如果满了，就扩容4倍，且当元素总数达到50000时，再扩容就改为2倍。

Python 列表的数据结构是怎么样的？
书上说的是：列表实现可以是数组和链表。
顺序表是怎么回事？顺序表一般是数组。
列表是一个线性的集合，它允许用户在任何位置插入、删除、访问和替换元素。
列表实现是基于数组或基于链表结构的。当使用列表迭代器的时候，双链表结构比单链表结构更快。
有序的列表是元素总是按照升序或者降序排列的元素。
实现细节
python中的列表的英文名是list，因此很容易和其它语言(C++, Java等)标准库中常见的链表混淆。事实上CPython的列表根本不是列表（可能换成英文理解起来容易些：python中的list不是list）。在CPython中，列表被实现为长度可变的数组。
可参考《Python高级编程（第2版）》
从细节上看，Python中的列表是由对其它对象的引用组成的连续数组。指向这个数组的指针及其长度被保存在一个列表头结构中。这意味着，每次添加或删除一个元素时，由引用组成的数组需要该标大小（重新分配）。幸运的是，Python在创建这些数组时采用了指数分配，所以并不是每次操作都需要改变数组的大小。但是，也因为这个原因添加或取出元素的平摊复杂度较低。
不幸的是，在普通链表上“代价很小”的其它一些操作在Python中计算复杂度相对过高。
利用 list.insert(i,item) 方法在任意位置插入一个元素——复杂度O(N)
利用 list.pop(i) 或 list.remove(value) 删除一个元素——复杂度O(N)
列表的算法效率
可以采用时间复杂度来衡量：
index() O(1)
append O(1)
pop() O(1)
pop(i) O(n)
insert(i,item) O(n)
del operator O(n)
iteration O(n)
contains(in) O(n)
get slice[x:y] O(k)
del slice O(n)
set slice O(n+k)
reverse O(n)
concatenate O(k)
sort O(nlogn)
multiply O(nk)
O括号里面的值越大代表效率越低
列表和元组
列表和元组的区别是显然的：
列表是动态的，其大小可以该标 (重新分配)；
而元组是不可变的，一旦创建就不能修改。
list和tuple在c实现上是很相似的，对于元素数量大的时候，
都是一个数组指针，指针指向相应的对象，找不到tuple比list快的理由。
但对于小对象来说，tuple会有一个对象池，所以小的、重复的使用tuple还有益处的。
为什么要有tuple，还有很多的合理性。
实际情况中的确也有不少大小固定的列表结构，例如二维地理坐标等；
另外tuple也给元素天然地赋予了只读属性。
认为tuple比list快的人大概是把python的tuple和list类比成C++中的数组和列表了。
相关文档
深入 Python 列表的内部实现：http://python.jobbole.com/82549/
[python]list, tuple, dictionary, set的底层细节：https://blog.csdn.net/siyue0211/article/details/80560783
Python列表：初学者应该懂得操作和内部实现：https://mp.weixin.qq.com/s/IkFak4iYYqW7u61P7eu22g
python学习笔记 – list内部实现：https://www.jianshu.com/p/cd75475168ae
从底层理解Python的执行：https://www.csdn.net/article/2015-05-28/2824795