list() 使用的内存比列表推导略多
list() uses slightly more memory than list comprehension
所以我在玩 list 对象并发现一点奇怪的事情，如果 list 是用 list() 创建的，它使用的内存比列表理解更多？我正在使用 Python 3.5.2
In [1]: import sys
In [2]: a = list(range(100))
In [3]: sys.getsizeof(a)
Out[3]: 1008
In [4]: b = [i for i in range(100)]
In [5]: sys.getsizeof(b)
Out[5]: 912
In [6]: type(a) == type(b)
Out[6]: True
In [7]: a == b
Out[7]: True
In [8]: sys.getsizeof(list(b))
Out[8]: 1008
来自docs：
Lists may be constructed in several ways:
- Using a pair of square brackets to denote the empty list:
[]
- Using square brackets, separating items with commas:
[a], [a, b, c]
- Using a list comprehension:
[x for x in iterable]
- Using the type constructor:
list() or list(iterable)
但似乎使用 list() 它会占用更多内存。
list越大，差距越大。
为什么会这样？
更新 #1
使用 Python 3.6.0b2 进行测试：
Python 3.6.0b2 (default, Oct 11 2016, 11:52:53)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.getsizeof(list(range(100)))
1008
>>> sys.getsizeof([i for i in range(100)])
912
更新 #2
使用 Python 2.7.12 测试：
Python 2.7.12 (default, Jul 1 2016, 15:12:24)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.getsizeof(list(xrange(100)))
1016
>>> sys.getsizeof([i for i in xrange(100)])
920
我认为您看到了过度分配模式，这是 sample from the source:
/* This over-allocates proportional to the list size, making room
* for additional growth. The over-allocation is mild, but is
* enough to give linear-time amortized behavior over a long
* sequence of appends() in the presence of a poorly-performing
* system realloc().
* The growth pattern is: 0, 4, 8, 16, 25, 35, 46, 58, 72, 88, ...
*/
new_allocated = (newsize >> 3) + (newsize < 9 ? 3 : 6);
打印长度为 0-88 的列表理解的大小，您可以看到模式匹配：
# create comprehensions for sizes 0-88
comprehensions = [sys.getsizeof([1 for _ in range(l)]) for l in range(90)]
# only take those that resulted in growth compared to previous length
steps = zip(comprehensions, comprehensions[1:])
growths = [x for x in list(enumerate(steps)) if x[1][0] != x[1][1]]
# print the results:
for growth in growths:
print(growth)
结果（格式为(list length, (old total size, new total size))）：
(0, (64, 96))
(4, (96, 128))
(8, (128, 192))
(16, (192, 264))
(25, (264, 344))
(35, (344, 432))
(46, (432, 528))
(58, (528, 640))
(72, (640, 768))
(88, (768, 912))
过度分配是出于性能原因，允许列表增长而无需在每次增长时分配更多内存（更好的 amortized 性能）。
与使用列表推导不同的一个可能原因是列表推导无法确定性地计算生成列表的大小，但 list() 可以。这意味着理解会在使用过度分配填充列表时不断增长列表，直到最终填充它。
一旦完成，可能不会增加未使用的已分配节点的过度分配缓冲区（事实上，在大多数情况下它不会，这将破坏过度分配的目的）。
list()，但是，无论列表大小如何，都可以添加一些缓冲区，因为它提前知道最终列表大小。
另一个同样来自源的支持证据是我们看到 list comprehensions invoking LIST_APPEND，这表明 list.resize 的使用，这反过来表明在不知道有多少预分配缓冲区的情况下使用了它将被填满。这与您看到的行为一致。
总而言之，list() 将根据列表大小预分配更多节点
>>> sys.getsizeof(list([1,2,3]))
60
>>> sys.getsizeof(list([1,2,3,4]))
64
列表理解不知道列表大小，因此它在增长时使用追加操作，耗尽预分配缓冲区：
# one item before filling pre-allocation buffer completely
>>> sys.getsizeof([i for i in [1,2,3]])
52
# fills pre-allocation buffer completely
# note that size did not change, we still have buffered unused nodes
>>> sys.getsizeof([i for i in [1,2,3,4]])
52
# grows pre-allocation buffer
>>> sys.getsizeof([i for i in [1,2,3,4,5]])
68
感谢大家帮助我理解那个很棒的 Python。
我不想提出那么大的问题（这就是我发布答案的原因），只是想展示和分享我的想法。
正如 @ReutSharabani 正确指出的那样："list() deterministically determines list size"。你可以从那个图中看到它。
当您 append 或使用列表理解时，您总会有某种边界，当您到达某个点时，边界会延伸。 list() 你有几乎相同的边界，但它们是浮动的。
更新
感谢@ReutSharabani、@tavo、@SvenFestersen
总结一下：list() 预分配内存取决于列表大小，列表推导无法做到这一点（它在需要时请求更多内存，如 .append()）。这就是 list() 存储更多内存的原因。
另一个图表，显示 list() 预分配内存。所以绿线显示 list(range(830)) 一个元素一个元素地追加，一段时间内存没有改变。
更新 2
正如@Barmar 在下面的评论中指出的那样，list() 必须比列表理解更快，所以我 运行 timeit() 和 number=1000 的长度为 list 从 4**0 到 4**10 结果是
所以我在玩 list 对象并发现一点奇怪的事情，如果 list 是用 list() 创建的，它使用的内存比列表理解更多？我正在使用 Python 3.5.2
In [1]: import sys
In [2]: a = list(range(100))
In [3]: sys.getsizeof(a)
Out[3]: 1008
In [4]: b = [i for i in range(100)]
In [5]: sys.getsizeof(b)
Out[5]: 912
In [6]: type(a) == type(b)
Out[6]: True
In [7]: a == b
Out[7]: True
In [8]: sys.getsizeof(list(b))
Out[8]: 1008
来自docs：
Lists may be constructed in several ways:
- Using a pair of square brackets to denote the empty list:
[]- Using square brackets, separating items with commas:
[a],[a, b, c]- Using a list comprehension:
[x for x in iterable]- Using the type constructor:
list()orlist(iterable)
但似乎使用 list() 它会占用更多内存。
list越大，差距越大。
为什么会这样？
更新 #1
使用 Python 3.6.0b2 进行测试：
Python 3.6.0b2 (default, Oct 11 2016, 11:52:53)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.getsizeof(list(range(100)))
1008
>>> sys.getsizeof([i for i in range(100)])
912
更新 #2
使用 Python 2.7.12 测试：
Python 2.7.12 (default, Jul 1 2016, 15:12:24)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.getsizeof(list(xrange(100)))
1016
>>> sys.getsizeof([i for i in xrange(100)])
920
我认为您看到了过度分配模式，这是 sample from the source:
/* This over-allocates proportional to the list size, making room
* for additional growth. The over-allocation is mild, but is
* enough to give linear-time amortized behavior over a long
* sequence of appends() in the presence of a poorly-performing
* system realloc().
* The growth pattern is: 0, 4, 8, 16, 25, 35, 46, 58, 72, 88, ...
*/
new_allocated = (newsize >> 3) + (newsize < 9 ? 3 : 6);
打印长度为 0-88 的列表理解的大小，您可以看到模式匹配：
# create comprehensions for sizes 0-88
comprehensions = [sys.getsizeof([1 for _ in range(l)]) for l in range(90)]
# only take those that resulted in growth compared to previous length
steps = zip(comprehensions, comprehensions[1:])
growths = [x for x in list(enumerate(steps)) if x[1][0] != x[1][1]]
# print the results:
for growth in growths:
print(growth)
结果（格式为(list length, (old total size, new total size))）：
(0, (64, 96))
(4, (96, 128))
(8, (128, 192))
(16, (192, 264))
(25, (264, 344))
(35, (344, 432))
(46, (432, 528))
(58, (528, 640))
(72, (640, 768))
(88, (768, 912))
过度分配是出于性能原因，允许列表增长而无需在每次增长时分配更多内存（更好的 amortized 性能）。
与使用列表推导不同的一个可能原因是列表推导无法确定性地计算生成列表的大小，但 list() 可以。这意味着理解会在使用过度分配填充列表时不断增长列表，直到最终填充它。
一旦完成，可能不会增加未使用的已分配节点的过度分配缓冲区（事实上，在大多数情况下它不会，这将破坏过度分配的目的）。
list()，但是，无论列表大小如何，都可以添加一些缓冲区，因为它提前知道最终列表大小。
另一个同样来自源的支持证据是我们看到 list comprehensions invoking LIST_APPEND，这表明 list.resize 的使用，这反过来表明在不知道有多少预分配缓冲区的情况下使用了它将被填满。这与您看到的行为一致。
总而言之，list() 将根据列表大小预分配更多节点
>>> sys.getsizeof(list([1,2,3]))
60
>>> sys.getsizeof(list([1,2,3,4]))
64
列表理解不知道列表大小，因此它在增长时使用追加操作，耗尽预分配缓冲区：
# one item before filling pre-allocation buffer completely
>>> sys.getsizeof([i for i in [1,2,3]])
52
# fills pre-allocation buffer completely
# note that size did not change, we still have buffered unused nodes
>>> sys.getsizeof([i for i in [1,2,3,4]])
52
# grows pre-allocation buffer
>>> sys.getsizeof([i for i in [1,2,3,4,5]])
68
感谢大家帮助我理解那个很棒的 Python。
我不想提出那么大的问题（这就是我发布答案的原因），只是想展示和分享我的想法。
正如 @ReutSharabani 正确指出的那样："list() deterministically determines list size"。你可以从那个图中看到它。
当您 append 或使用列表理解时，您总会有某种边界，当您到达某个点时，边界会延伸。 list() 你有几乎相同的边界，但它们是浮动的。
更新
感谢@ReutSharabani、@tavo、@SvenFestersen
总结一下：list() 预分配内存取决于列表大小，列表推导无法做到这一点（它在需要时请求更多内存，如 .append()）。这就是 list() 存储更多内存的原因。
另一个图表，显示 list() 预分配内存。所以绿线显示 list(range(830)) 一个元素一个元素地追加，一段时间内存没有改变。
更新 2
正如@Barmar 在下面的评论中指出的那样，list() 必须比列表理解更快，所以我 运行 timeit() 和 number=1000 的长度为 list 从 4**0 到 4**10 结果是