[Python-ideas] x=(yield from) confusion [was:Yet another alternative name for yield-from]

[Guido van Rossum]

On Wed, Apr 8, 2009 at 8:04 AM, Jacob Holm <jh at improva.dk> wrote:
> Jacob Holm wrote:
>> Even assuming every relevant object implemented the pattern I suggest, it
>> is still not possible to use yield-from to write something like
>> itertools.dropwhile and have it delegate all send and throw calls correctly.
>> To make that possible, you need exactly the same thing that you need for
>> pre-started coroutines: The ability to replace the next() call made by the
>> yield-from expression with something else. Give me that, and you will also
>> have removed the need for a special pattern for coroutines that should be
>> usable with yield-from.
>
> To be clear, I think the best way of handling this is to add a read-only
> property to generator objects holding the latest value yielded, and let
> yield-from use that when present instead of calling next(). (This is not a
> new idea, I am just explaining the consequences as I see them). The property
> can be cleared when the frame is released, so there should be no issues with
> that.

Let me just respond with the recommendation that you stop pushing for
features that require storing state on the generator object. Quite
apart from implementation issues (which may well be non-existent) I
think it's a really scary thing to add any "state" to a generator that
isn't contained naturally in its stack frame.

If this means that you can't use yield-from for some of your use
cases, well, so be it. It has plenty of other use cases.

And no, I am not prepared to defend this recommendation. But I feel
very strongly about it. So don't challenge me -- it's just going to be
a waste of everyone's time to continue this line of thought.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)