Dangerous behavior of list(generator)

[Lie Ryan]

On 12/14/2009 9:45 AM, exarkun at twistedmatrix.com wrote:
> On 08:18 pm, steve at remove-this-cybersource.com.au wrote:
>> On Sun, 13 Dec 2009 14:35:21 +0000, exarkun wrote:
>>>> StopIteration is intended to be used only within the .__next__
>>>> method of
>>>> iterators. The devs know that other 'off-label' use results in the
>>>> inconsistency you noted, but their and my view is 'don't do that'.
>>>
>>> Which is unfortunate, because it's not that hard to get StopIteration
>>> without explicitly raising it yourself and this behavior makes it
>>> difficult to debug such situations.
>>
>> I can't think of any way to get StopIteration without explicitly raising
>> it yourself. It's not like built-ins or common data structures routinely
>> raise StopIteration. I don't think I've *ever* seen a StopIteration that
>> I didn't raise myself.
>
> Call next on an iterator. For example: iter(()).next()

.next() is not meant to be called directly, that's why it's renamed to 
.__next__() in python 3. Just like .__add__() is never meant to be 
called directly since you'll then have to handle NotImplemented.

If you really need to call .__next__() you will call next() builtin 
function instead which has a second argument to return a sentinel value 
instead of StopIteration. IMNSHO next()'s sentinel should always be 
specified except if you're implementing __next__() or if the sequence is 
an infinite iterator.

>>> What's with this view, exactly? Is it just that it's hard to implement
>>> the more desirable behavior?
>>
>> What is that "more desirable behaviour"? That StopIteration is used to
>> signal that Python should stop iterating except when you want it to be
>> ignored? Unfortunately, yes, it's quite hard to implement "do what the
>> caller actually wants, not what he asked for" behaviour -- and even if it
>> were possible, it goes against the grain of the Zen of Python.
>>
>> If you've ever had to debug faulty "Do What I Mean" software, you'd see
>> this as a good thing.
>
> I have plenty of experience developing and debugging software, Steven.
> Your argument is specious, as it presupposes that only two possibilities
> exist: the current behavior of some kind of magical faerie land behavior.
>
> I'm surprised to hear you say that the magical faerie land behavior
> isn't desirable either, though. I'd love a tool that did what I wanted,
> not what I asked. The only serious argument against this, I think, is
> that it is beyond our current ability to create (and so anyone claiming
> to be able to do it is probably mistaken).

In your world, this is what happens:
 >>> list = [a, b, c]
 >>> # print list
 >>> print list
["a", "b", "c"]
 >>> # make a copy of list
 >>> alist = list(llst) # oops a mistype
 >>> alist = alist - "]" + ", "d"]"
 >>> print alist
["a", "b", "c", "d"]
 >>> alist[:6] + "i", + alist[6:]
 >>> print alist
["a", "i", "b", "c", "d"]
 >>> print alist
 >>> # hearing the sound of my deskjet printer...
 >>> C:\fikle.text.write(alist)
 >>> print open("C:\file.txt").read()
<h1>a</h1>
<ul>
<li>i</li>
<li>b</li>
<li>c d</li>
 >>> # great, exactly what I needed

> You chopped out all the sections of this thread which discussed the more
> desirable behavior. You can go back and read them in earlier messages if
> you need to be reminded. I'm not talking about anything beyond what's
> already been raised.
>
> I'm pretty sure I know the answer to my question, though - it's hard to
> implement, so it's not implemented.
>
> Jean-Paul