I think the discussion is sort of missing a very common use case, when a
user calls func(iterator) and the function is expecting an iterable but not
an iterator. The author of the called code might be thinking that the input
is a list but that doen't mean the caller thinks that. Even worse is a case
like this:
def func(data_list):
if VERBOSE:
log(... [ ... for i in data_list ... ] ...)
for i in data_list :
do stuff with i
The behavor of this code changes (significantly!) when VERBOSE is set.
That's going to make debugging hard. [Yes, I know this can be safely
written using itertools.tee. That doesn't mean that everyone will do that.]
Here's a simple way to describe what the behavior could be (although
obviously this doesn't work):
def safer_iter_behavior(iterator):
yield from iterator
raise StopIteration
raise RuntimeError
That is, when you iterate the first time, it acts as expected, raising
StopIteration when the list is exhausted. If you continue to iterate after
the list is exhausted, it raises RuntimeError. In addition to the double
iteration case above, it guards against other cases like:
for x in iterator1:
y = next(iterator2)
do stuff
when the iterator2 is unexpectedly shorter than iterator1. Of course,
naively guarding against that by adding
if len(iterator1) != len(iterator2): ...
would be a bad idea and would also result in RuntimeError.
--- Bruce
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/SLDHXO5JBFKDVQGT7KD5HWEXIVPH7VLV/
Code of Conduct: http://python.org/psf/codeofconduct/
