[Python-ideas] Yield-From: Finalization guarantees

[Nick Coghlan]

Greg Ewing wrote:
> But if you need explicit wrappers to prevent finalization,
> then you hardly have "no implicit finalization". So I'm a
> bit confused about what behaviour you're really asking for.

I should have said no *new* mechanism for implicit finalisation.
Deletion of the outer generator would, as you say, still call close()
and throw GeneratorExit in.

I like it because the rules are simple: either an exception is thrown in
 and passed down to the subiterator (which may have the effect of
finalising it), or else the subiterator is left alone (to be finalised
either explicitly or implicitly when it is deleted).

There's then no special case along the lines of "if GeneratorExit is
passed in we just drop our reference to the subiterator instead of
passing the exception down", or "if you iterate over a subiterator using
'yield from' instead of a for loop then the subiterator will
automatically be closed at the end of the expression".

No matter what you do with regards to finalisation, you're going to
demand extra work from somebody. The simple rule means that subiterators
will see all exceptions (even GeneratorExit), allowing them to handle
their own finalisation needs, while  shareable subiterators are also
possible so long as they don't have throw() methods.

The idea of a shareable iterator that *does* support send() or throw()
just doesn't make any sense to me. Splitting up a data feed amongst
multiple peer consumers, OK, that's fairly straightforward and I can
easily imagine uses for it in a generator based coding style (e.g.
having multiple clients pulling requests from a job queue). But having
multiple peer writers attempting to feed values or exceptions back into
that single iterator that can neither tell which writer a particular
value or exception came from, nor direct results to particular
consumers? That sounds like utter insanity. If you want to create a
shareable iterator, preventing use of send() and throw() strikes me as a
*very* good idea.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------