根据文件:
一旦迭代器的
__next__()方法引发StopIteration,它必须继续在后续调用中这样做.不遵守此属性的实现被视为已损坏.
但是,对于文件对象:
>>> f = open('test.txt')
>>> list(f)
['a\n', 'b\n', 'c\n', '\n']
>>> next(f)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
StopIteration
>>> f.seek(0)
0
>>> next(f)
'a\n'
Run Code Online (Sandbox Code Playgroud)
文件对象迭代器是否已损坏?这只是其中一个无法解决的问题,因为它会破坏过多依赖它的现有代码吗?
我认为这就是该段落上的文档错误,而不是io对象中的错误.(并且io对象不是唯一的 - 最简单的是,csv.reader文件的包装器就像文件一样可以重启.)
如果你只是使用迭代器作为迭代器,一旦它加注它将继续提升.但是如果你调用迭代器协议之外的方法,你就不再将它作为迭代器了,而是作为迭代器而不是迭代器.在这种情况下,如果有意义的话,对象"可再填充"似乎是合法的,甚至是惯用的.只要它在作为迭代器嘎嘎作响时它永远不会重新填充,只有当它像其他类型的东西嘎嘎叫时才会超越它.
在C++中的类似情况下,语言委员会可能会声明这会破坏可替代性,因此一旦你在其上调用这样的方法,迭代器就会变成无效的迭代器,即使语言不能强制执行.或者为可再填充的迭代器提出一个全新的协议.(当然C++迭代器与Python迭代器并不完全相同,但希望你得到我的意思.)
但在Python中,实用性胜过纯洁.我很确定Guido从一开始就想要这种行为,并且允许一个对象执行此操作并仍被视为迭代器,并且核心开发人员继续打算使用它,并且只是没有人想过如何编写某些东西足够严谨,准确地解释它,因为没有人问过.
如果你通过提交文档错误提出要求,我敢打赌这个段落会得到一个脚注,而不是io其他可再填充的迭代器对象被重新分类为实际的迭代器.
| 归档时间: |
|
| 查看次数: |
213 次 |
| 最近记录: |