On 12/14/2009 9:45 AM, exar...@twistedmatrix.com wrote:
On 08:18 pm, st...@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
--
http://mail.python.org/mailman/listinfo/python-list
