Python length_hint 的估计值：提示还有八项，为什么最终只读出了三项
给一批记录分配缓冲区时，希望先知道大概有多少项。调用length_hint拿到八，却只读出三项，很容易误判为数据丢失。这个接口允许返回估计值，结果可以偏大也可以偏小；它表达的是优化机会，不能替代真正的迭代结束信号。
本例在Linux、CPython 3.12.14实跑。把完整程序保存为demo.py，运行python3 demo.py。所有对象都在内存，数据只有几个整数；故意让提示值与实际数量不同，再观察真实长度、备用值及错误提示的不同入口。
AI生成的概念示意图：虚线容量与实际输出的实体块分开呈现，表示估计和事实可能不同；不是内存布局图。
完整程序与本地结果
完整可运行程序
from operator import length_hint
class Estimated:
def __iter__(self):
return iter((10, 20, 30))
def __length_hint__(self):
return 8
source = Estimated()
print("estimated:", length_hint(source))
actual = list(source)
assert actual == [10, 20, 30]
print("actual:", actual, "count:", len(actual))
class Exact(Estimated):
def __len__(self):
return 3
assert length_hint(Exact()) == 3
print("len takes priority:", length_hint(Exact()))
stream = (value for value in (4, 5))
assert length_hint(stream, 9) == 9
print("fallback hint:", length_hint(stream, 9))
assert list(stream) == [4, 5]
print("generator was not consumed: True")
class Invalid(Estimated):
def __length_hint__(self):
return -1
try:
length_hint(Invalid(), 9)
except ValueError:
print("negative hint: ValueError")
else:
raise AssertionError("negative estimate accepted")本次实际输出（以下为结果，不是程序）
estimated: 8 actual: [10, 20, 30] count: 3 len takes priority: 3 fallback hint: 9 generator was not consumed: True negative hint: ValueError
八只是提示，三才是本次遍历结果
Estimated没有定义真实长度，但提供了返回八的__length_hint__。它的__iter__每次创建一个只含十、二十、三十的迭代器。输出先显示estimated为八，随后actual只有三项，断言也明确核对三项内容，说明提示不会凭空生成额外记录。
这里转成列表只是为了观察固定小样本。假如按提示预先建立八格存储，处理完以后应记录实际写入数，而不是把其余五格当成有效空值。反过来，估计偏小时也要能扩展容量或分批处理，不能静默截断后来出现的数据。
真实长度存在时，它排在提示前面
Exact继承了返回八的提示方法，又增加返回三的__len__。length_hint给出的却是三。这个对照说明调用优先尝试实际长度，不能只找到类里存在__length_hint__，就断言最终一定采用那个方法的值。
排查自定义集合时，可以分别检查长度协议和提示协议是否同时实现、各自承诺什么。不要为了让进度条看起来方便，就把不准确的预测放进__len__；真实长度与估计信息承担不同责任，调用者有权依赖真实长度的语义。
备用值不会替你数完生成器
普通生成器没有提供这个例子所需的长度信息，于是显式传入的备用值九被返回。紧接着仍然能够完整读取四和五，证明这次探测没有为了得到九而先消费输入。这里的九来自调用方选择，与生成器实际会产生几项没有必然关系。
因此备用值零也不能被解释为“输入肯定为空”。在没有长度信息的流式处理中，应直接遍历到StopIteration，或采用业务规定的数量、时间上限。若用户界面必须显示总进度，宁可标为未知，也不要把备用值包装成确定总量。
提示非法时，不会自动变成备用值
Invalid返回负一，调用抛出ValueError，即使同时给了备用值九也一样。负数违反提示协议，和完全没有提示不是同一情形。捕获异常后偷偷当作零处理，会把实现缺陷伪装成空集合，让下游难以发现真正的问题。
自定义提示应返回非负整数，或者用协议允许的NotImplemented表示不提供估计。本文只实际演示负数错误，没有穷举所有异常；方法本身还可能执行自定义代码并抛出其他错误，所以探测也不是无副作用的通用检查。
容量优化与业务正确性分别验证
验收一个使用提示的消费者，可以让同一组实际记录分别配上零、准确数量和较大估计，检查最终结果始终一致。差异应该体现在分配策略上，而不是记录内容、完成判断或异常是否被吞掉；否则优化信息已经越过了它的使用边界。
本文不测量列表实际预留多少内存，也不承诺某个解释器一定怎样利用提示。若要比较性能，应单独设计可复现的容量与耗时实验。这里只验证公开协议和可见结果，确保关闭这种优化后，程序仍能正确处理同一份输入。
如果外部输入可以控制估计值，也别直接按一个巨大提示申请等量业务资源。可以设置合理的初始容量上限，随后随实际数据增长；这个上限限制的是优化预算，不应顺带限制允许处理的记录总数。
参考资料
资料核验日期：2026年10月2日。以上输出来自固定输入的本地实跑，退出码为0。
