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