为什么列表询问__len__？

为什么列表询问__len__？

请参阅PEP
424
的“基本原理”部分，该部分介绍

__length_hint__

并提供了有关动机的见解：

能够根据预期大小（由估算）预先分配列表

__length_hint__

可能是一项重大优化。
观察到CPython比PyPy运行某些代码快，完全是因为存在这种优化。

除此之外，用于的文档还

object.__length_hint__

验证了这纯粹是一项优化功能：

叫执行

operator.length_hint()

。应该返回对象的估计长度（可以大于或小于实际长度）。长度必须是整数

>= 0

。 此方法
纯粹是一种优化 ，对于正确性从来不需要
。

__length_hint__

之所以如此，是因为它可以带来一些不错的优化。

PyObject_LengthHint

，首先尝试从中获取值

object.__len__

（如果已定义），然后尝试查看是否

object.__length_hint__

可用。如果两者都不存在，则返回

8

for列表的默认值。

listextend``list_init

如Eli在其答案中所述被调用，根据此PEP进行了修改，以为定义a

__len__

或a的任何内容提供此优化

__length_hint__

。

list

不是唯一受益于此的

bytes

对象，对象当然可以这样做：

>>> bytes(Foo())lengetitem 0...b'x00x01x04tx10x19'

对象也是如此，

bytearray

但只有当您使用

extend

它们时：

>>> bytearray().extend(Foo())lengetitem 0...

和

tuple

创建中间序列以填充自身的对象：

>>> tuple(Foo())lengetitem 0...(0, 1, 4, 9, 16, 25)

---

如果有人在徘徊，为什么在上课 之前 而不是在上课之后

'iter'

打印确切的内容： __

'len'``Bar``Foo

这是因为如果手中的对象定义了

__iter__

Python， 则将首先调用它
来获取迭代器，从而也运行它

print('iter')

。如果回到使用，则不会发生相同的情况

__getitem__

。