Python迭代器抛出StopIteration后是否必须永久停止？

违反迭代器协议的实际风险 #

你当前的实现如果只用于for ... in receiver遍历、手动调用next(receiver)这两种简单场景，确实不会出问题，但风险来源于和Python生态默认约定的兼容性：

• Python内置的list()、tuple()等容器构造函数，以及itertools模块下的所有工具（islice、chain、filterfalse等），全部默认迭代器一旦抛出StopIteration就已经永久耗尽，不会再尝试调用__next__。比如你先遍历完一次接收器抛出StopIteration后，再调用list(receiver)永远会返回空列表，哪怕此时队列已经有新的数据包。
• 大量第三方库的迭代处理逻辑也遵循同样的约定，如果你把这个接收器对象传入这类通用处理函数，会出现无报错但数据丢失的隐性问题，排查成本极高。

你的三个顾虑都有合规的解决方案 #

完全不用违背迭代器协议就能满足你的所有需求：

支持next(receiver)手动取包 #

你可以保留__next__方法实现取包逻辑，只需要调整语义边界：把「队列当前为空」和「接收器永久关闭、再也不会有新包」两种场景分开：

• 队列暂时为空时不要抛StopIteration，改为抛自定义的Empty异常（参考标准库queue.Queue的设计）
• 只有接收器真的永久关闭时，才抛出StopIteration，之后永远保持抛出该异常，符合协议要求

如果需要实现「遍历当前所有可用包后自动结束for循环」的效果，只需要把__iter__实现为生成器即可：

def __iter__(self):
    while True:
        try:
            yield self.__next__()
        except Empty:
            # 遍历完当前所有包，结束迭代，该生成器永久耗尽符合协议要求
            return

每次for循环会自动调用iter(receiver)生成新的生成器迭代器，只会遍历当前时刻队列中已有的所有包，完全符合你的使用直觉。

迭代器开销完全可以忽略 #

每次生成的生成器迭代器只有非常低的内存开销，比你调用C库接口、处理数据包的开销低至少两个数量级，完全不存在浪费的问题，不需要担心性能损耗。

多迭代器抢包的语义问题 #

这个问题和你是否符合迭代器协议无关，本身是消费型队列的固有特性。你只需要在文档中明确标注接收器是消费型资源，所有取包操作（包括迭代遍历）都会消费数据包，多迭代器/多线程同时取包会出现争抢，用户自然会规避这类用法。反而你违背迭代器协议带来的隐性兼容问题，是用户很难预判和排查的，风险远高于明确的抢包语义。

要不要修改的判断标准 #

• 如果这个接收器只是你个人项目内部使用，所有相关代码都由你自己维护，也不会用到通用迭代工具处理它，你可以保留现有实现，没有强制修改的必要。
• 如果你要把这个实现作为公共库对外发布，或者项目中会用到itertools等通用迭代工具，强烈建议你调整为符合协议的实现，避免后续出现难以排查的隐性bug。

内容的提问来源于stack exchange，提问作者JustinFisher