On 02:58 pm, m...@egenix.com wrote:
exar...@twistedmatrix.com wrote:
On 08:45 am, tjre...@udel.edu wrote:
Tom Machinski wrote:
In most cases, `list(generator)` works as expected. Thus,
`list(<generator expression>)` is generally equivalent to `[<generator
expression>]`.

Here's a minimal case where this equivalence breaks, causing a serious
and hard-to-detect bug in a program:

  >>> def sit(): raise StopIteration()

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.

What's with this view, exactly? Is it just that it's hard to implement
the more desirable behavior?

I'm not exactly sure what you're asking for.

The StopIteration exception originated as part of the for-loop
protocol. Later on it was generalized to apply to generators
as well.

The reason for using an exception is simple: raising and catching
exceptions is fast at C level and since the machinery for
communicating exceptions up the call stack was already there
(and doesn't interfere with the regular return values), this
was a convenient method to let the upper call levels know
that an iteration has ended (e.g. a for-loop 4 levels up the
stack).

I'm not sure whether that answers your question, but it's the
reason for things being as they are :-)

I'm asking about why the behavior of a StopIteration exception being handled from the `expression` of a generator expression to mean "stop the loop" is accepted by "the devs" as acceptable. To continue your comparison to for loops, it's as if a loop like this:

   for a in b:
       c

actually meant this:

   for a in b:
       try:
           c
       except StopIteration:
           break

Note, I know *why* the implementation leads to this behavior. I'm asking why "the devs" *accept* this.

Jean-Paul
--
http://mail.python.org/mailman/listinfo/python-list

Reply via email to