John Nagle <na...@animats.com> writes: > PEP 255, like too much Python literature, doesn't distinguish > clearly between the language definition and implementation detail. It > says "The mechanics of StopIteration are low-level details, much like > the mechanics of IndexError in Python 2.1". Applications shouldn't be > explicitly using StopIteration.
You've twisted the words by quoting them out of context, and have attempted to force a misinterpretation of `low-level details' as `implementation detail'. That text comes from a question-and-answer section, in response to the question `why not force termination to be spelled "StopIteration"?'. This is a fine answer to the question: the details of the (preexisting -- see PEP 234) iteration protocol are abstracted by the generator syntax. But it doesn't at all mean that the StopIteration exception isn't an official, use-visible part of Python. > IronPython doesn't do StopIteration the same way CPython does. > > http://ironpython.codeplex.com/wikipage?title=IPy1.0.xCPyDifferences IronPython's behaviour when you try to fetch items from a spent generator is different. It still implements the same iterator protocol, and raises StopIteration when it has no more items to yield. You're not stupid, but you'd have to be in order to think that these references support your claim that > >> You're not entitled to assume that StopIteration is how a generator > >> exits. That's a CPyton thing; generators were a retrofit, and > >> that's how they were hacked in. Other implementations may do > >> generators differently. I don't want to conclude that you're not arguing in good faith but I'm not seeing many other possibilities. -- [mdw] -- http://mail.python.org/mailman/listinfo/python-list
