共计 4538 个字符，预计需要花费 12 分钟才能阅读完成。
在浏览《晦涩的 python》以及《深刻了解 python 个性》时发现这两本书都提及了 python 的一个库：collection.namedtuple，这个库能够疾速的创立一个 tuple 对象并且能够为其命令，而且输入查看该对象值时，tuple 中是以 key=value 的模式存储，不便了用户的应用，最次要的是：这个对象在内存中所耗费的字节数与一般 tuple 一样！
>>> from collections import namedtuple
>>> Card = namedtuple('Card',"rank suit")
>>> Card
<class '__main__.Card'>
>>> type(Card)
<class 'type'>
>>> ranks = [str(n) for n in range(2,11)] +list("JQKA")
>>> suits = 'spades diamonds clubs hearts'
>>> cards = [Card(rank,suit) for rank in ranks for suit in suits]
>>> cards
[Card(rank='2', suit='s'), Card(rank='2', suit='p'), Card(rank='2', suit='a'), Card(rank='2', suit='d'), Card(rank='2', suit='e'), Card(rank='2', suit='s'), Card(rank='2', suit=' ')
前面省略能够发现应用了 namedtupe 后，每个 tuple 有了名称，而且存储格局为 key=value 的模式。
同时疾速创立牌组的列表的推到式应用于笛卡尔积这样的模式，疾速的构建 list，无论是一个变量，还是变量;
对于 tuple
都晓得 tuple 中存储的是不能轻易批改的变量值，那么上面这段代码批改后会发现什么状况呢？
>>> t = (1,2,[30,40])
>>> t[2]
[30, 40]
>>> t[2]+=[50,60]状况 1：因为 tuple 存储的是不可批改的变量，批改会产生谬误；
状况 2：因为 list 是可变对象，能够批改胜利；而且没有什么谬误提醒；
惋惜的是，批改后既提醒了谬误，也让用户批改了其中可变对象的值
>>> t = (1,2,[30,40])
>>> t[2]
[30, 40]
>>> t[2]+=[50,60]
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'tuple' object does not support item assignment
>>> t
(1, 2, [30, 40, 50, 60])对于 list
最近学习 list 的时候发现一个乏味的景象，那就是我切片的时候，切片范畴比赋予的值多时，发现竟然没有赋值的那一块局部的值竟然隐没了，留下代码记录一下:
>>> a = [1,2,3,4,5,6,7]
>>> a[2:5]=[33,44]
>>> a
[1, 2, 33, 44, 6, 7]能够说切片性能非常弱小，能够对序列进行嫁接、切除或就地批改操作。
对于 dict
dict 能够说是 python 中最弱小的数据结构，因为他能够很不便的通过 key 值查到 value；然而它破费的代价却是很大的，相比于 list 来说;
>>> import sys
>>> a = set()
>>> b = {}
>>> sys.getsizeof(a)
232
>>> sys.getsizeof(b)
248
>>> c = []
>>> sys.getsizeof(c)
72
>>> d = ()
>>> sys.getsizeof(d)
56能够发现一个字典要耗费 248 字节，汇合要耗费 232 字节，list 只须要 72 字节，而 tuple 只须要破费 56 字节！
对于 dict 的底层实现，下边是书中的话语，曾经解释的非常具体，无需我再添枝加叶;
散列表其实是一个稠密数组(总是有空白元素的数组称为稠密数组)。在个别的数据结构教材中，散列表里的单元通常叫作表元(bucket)。在 dict 的散列表当中，每个键值对都占用一个表元，每个表元都有两 个局部，一个是对键的援用，另一个是对值的援用。因为所有表元的大 小统一，所以能够通过偏移量来读取某个表元。
因为 Python 会设法保障大略还有三分之一的表元是空的，所以在快要达 到这个阈值的时候，原有的散列表会被复制到一个更大的空间外面。
如果要把一个对象放入散列表，那么首先要计算这个元素键的散列值。Python 中能够用 hash() 办法来做这件事件，接下来会介绍这一点。
- 散列值和相等性
内置的 hash() 办法能够用于所有的内置类型对象。如果是自定义 对象调用 hash() 的话，实际上运行的是自定义的 __hash__。如 果两个对象在比拟的时候是相等的，那它们的散列值必须相等，否 则散列表就不能失常运行了。例如，如果 1 == 1.0 为真，那么 hash(1) == hash(1.0) 也必须为真，但其实这两个数字 (整型 和浮点) 的内部结构是齐全不一样的。
为了让散列值可能胜任散列表索引这一角色，它们必须在索引空间 中尽量分散开来。这意味着在最现实的情况下，越是类似但不相等 的对象，它们散列值的差异应该越大。
- 散列表算法
为了获取 my_dict[search_key] 背地的值，Python 首先会调用 hash(search_key) 来计算 search_key 的散列值，把这个值最低的几位数字当作偏移量，在散列表里查找表元(具体取几位，得看 以后散列表的大小)。若找到的表元是空的，则抛出 KeyError 异 常。若不是空的，则表元里会有一对 found_key:found_value。这时候 Python 会测验 search_key == found_key 是否为真，如 果它们相等的话，就会返回 found_value。
如果 search_key 和 found_key 不匹配的话，这种状况称为散列 抵触。产生这种状况是因为，散列表所做的其实是把随机的元素映射到只有几位的数字上，而散列表自身的索引又只依赖于这个数字 的一部分。为了解决散列抵触，算法会在散列值中另外再取几位，而后用非凡的办法解决一下，把新失去的数字再当作索引来寻找表 元。若这次找到的表元是空的，则同样抛出 KeyError; 若非 空，或者键匹配，则返回这个值; 或者又发现了散列抵触，则反复 以上的步骤。
图 3-3 展现了这个算法的示意图。
图 3-3: 从字典中取值的算法流程图; 给定一个键，这个算法要 么返回一个值，要么抛出 KeyError 异样
增加新元素和更新现有键值的操作简直跟下面一样。只不过对于前者，在发现空表元的时候会放入一个新元素; 对于后者，在找到绝对应的表元后，原表里的值对象会被替换成新值。
另外在插入新值时，Python 可能会依照散列表的拥挤水平来决定是 否要从新分配内存为它扩容。如果减少了散列表的大小，那散列值所占的位数和用作索引的位数都会随之减少，这样做的目标是为了 缩小产生散列抵触的概率。
外表上看，这个算法仿佛很麻烦，而实际上就算 dict 里有数百万 个元素，少数的搜寻过程中并不会有抵触产生，均匀下来每次搜寻 可能会有一到两次抵触。在失常状况下，就算是最不背运的键所遇 到的抵触的次数用一只手也能数过来。
理解 dict 的工作原理能让咱们晓得它的所长和所短，以及从它衍 生而来的数据类型的优缺点。上面就来看看 dict 这些特点背地的 起因。
dict 的实现及其导致的后果
- 键必须是可散列的 一个可散列的对象必须满足以下要求。
(1) 反对 hash() 函数，并且通过 __hash__() 办法所失去的散列值是不变的。
(2) 反对通过 __eq__() 办法来检测相等性。
(3) 若 a == b 为真，则 hash(a) == hash(b) 也为真。所有由用户自定义的对象默认都是可散列的，因为它们的散列值由 id() 来获取，而且它们都是不相等的。
如果你实现了一个类的 eq 办法，并且心愿它是可 散列的，那么它肯定要有个失当的 hash 办法，保障在 a == b 为真的状况下 hash(a) == hash(b) 也必然为真。否则 就会毁坏恒定的散列表算法，导致由这些对象所组成的字典和 汇合齐全失去可靠性，这个结果是十分可怕的。另一方面，如 果一个含有自定义的 eq 依赖的类处于可变的状态，那就不要在这个类中实现 hash 办法，因为它的实例是不可散列的。
- 字典在内存上的开销微小
因为字典应用了散列表，而散列表又必须是稠密的，这导致它在空间上的效率低下。举例而言，如果你须要寄存数量微小的记录，那 么放在由元组或是具名元组形成的列表中会是比拟好的抉择; 最好
不要依据 JSON 的格调，用由字典组成的列表来寄存这些记录。用元组取代字典就能节俭空间的起因有两个: 其一是防止了散列表所 消耗的空间，其二是无需把记录中字段的名字在每个元素里都存一 遍。
在用户自定义的类型中，__slots__ 属性能够扭转实例属性的存储 形式，由 dict 变成 tuple，相干细节在 9.8 节谈判到。
记住咱们当初探讨的是空间优化。如果你手头有几百万个对象，而 你的机器有几个 GB 的内存，那么空间的优化工作能够等到真正需 要的时候再开始打算，因为优化往往是可维护性的对立面。
3. 键查问很快
dict 的实现是典型的空间换工夫: 字典类型有着微小的内存开 销，但它们提供了忽视数据量大小的快速访问——只有字典能被装在内存里。
4. 键的秩序取决于增加程序
当往 dict 里增加新键而又产生散列抵触的时候，新键可能会被安 排寄存到另一个地位。于是上面这种状况就会产生: 由 dict([key1, value1), (key2, value2)] 和 dict([key2, value2], [key1, value1]) 失去的两个字典，在进行比拟的时 候，它们是相等的; 然而如果在 key1 和 key2 被增加到字典里的过程中有抵触产生的话，这两个键呈现在字典里的程序是不一样 的。
- 往字典里增加新键可能会扭转已有键的程序
无论何时往字典里增加新的键，Python 解释器都可能做出为字典扩 容的决定。扩容导致的后果就是要新建一个更大的散列表，并把字 典里已有的元素增加到新表里。这个过程中可能会产生新的散列冲 突，导致新散列表中键的秩序变动。要留神的是，下面提到的这些 变动是否会产生以及如何产生，都依赖于字典背地的具体实现，因 此你不能很自信地说本人晓得背地产生了什么。如果你在迭代一个 字典的所有键的过程中同时对字典进行批改，那么这个循环很有可 能会跳过一些键——甚至是跳过那些字典中曾经有的键。
由此可知，不要对字典同时进行迭代和批改。如果想扫描并批改一 个字典，最好分成两步来进行: 首先对字典迭代，以得出须要增加 的内容，把这些内容放在一个新字典里; 迭代完结之后再对原有字 典进行更新。
这篇博客介绍 python3.6 当前的字典实现非常具体
https://zhuanlan.zhihu.com/p/…
Python3.6 之后，往字典里增加新键是有序的，不存在扭转已有键程序的状况了
同理，对于汇合来说，也是异样耗费内存的；汇合有如下特点：
1: 汇合里的元素必须是可散列的。
2: 汇合很耗费内存。
3: 能够很高效地判断元素是否存在于某个汇合。
4: 元素的秩序取决于被增加到汇合里的秩序。
5: 往汇合里增加元素，可能会扭转汇合里已有元素的秩序。
