Dangerous behavior of list(generator)

Steven D'Aprano steve at REMOVE-THIS-cybersource.com.au
Mon Dec 14 17:48:34 EST 2009


On Mon, 14 Dec 2009 14:31:44 +0000, exarkun wrote:

> On 06:46 am, tjreedy at udel.edu wrote:
>>On 12/13/2009 10:29 PM, exarkun at twistedmatrix.com wrote:
>>>Doesn't matter. Sometimes it makes sense to call it directly.
>>
>>It only makes sense to call next (or .__next__) when you are prepared to
>>explicitly catch StopIteration within a try..except construct. You did
>>not catch it, so it stopped execution.
>>
>>Let me repeat: StopIteration is intended only for stopping iteration.
>>Outside that use, it is a normal exception with no special meaning.
> 
> You cut out the part of my message where I wrote that one might have
> forgotten the exception handling code that you posit is required, and
> that the current behavior makes debugging this situation unnecessarily
> challenging.

I don't see why you think this is any more challenging to debug than any 
other equivalent bug. If anything I would think it was easier to debug: 
if the problem is that you get a StopIteration traceback, well that's 
easy and straightforward, and if the problem is that you don't (and 
consequently you end up with fewer items in the list than you expect), 
the obvious debugging technique is to build the list by hand and inspect 
each item before adding it to the list:

L = []
for i, item in enumerate(iterable):
    print i, item, 
    value = item()  # raises StopIteration
    print value
    L.append(value)

That will expose the StopIteration exception and reveal the problem.

But even if I have missed something, and it is a challenging problem to 
debug, oh well. It should be a quite unusual situation to come across.


-- 
Steven



More information about the Python-list mailing list