Exception handling in Python 3.x

[Mark Wooding]

John Nagle <nagle at 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]