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

[Guido van Rossum]

On Wed, Apr 8, 2009 at 7:52 PM, Jacob Holm <jh at improva.dk> wrote:
> Guido van Rossum wrote:
>>
>> On Wed, Apr 8, 2009 at 8:04 AM, Jacob Holm <jh at improva.dk> wrote:
>>
>>>
>>> Jacob Holm wrote:
>>> 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.
>>
>
> Does storing it as part of the frame object count as "naturally in the stack
> frame"?  Because that is probably the most natural place to put this,
> implementation-wise.

No, that's out too. My point is that I don't want to add *any* state
beyond what the user thinks of as the "normal" state in the frame
(i.e. local variables, where it is suspended, and the expression stack
and try-except stack). Nothing else.

> If storing on the frame object is also out, I will
> have to start thinking about new syntax again.  Oh well.

Sorry, no go. New syntax is also out.

> I was going to push for saving the final return value from a generator
> somewhere so that each StopIteration raised by an operation on the closed
> generator could have the same value as the StopIteration that closed it (or
> None if it was closed by another exception).  If that value can't live on
> the generator object, I guess that idea is dead.  Am I right?

Right.

>> 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.
>>
>
> That is exactly what I am worried about.  I think the number of use cases
> will be severely limited if we don't have a way to replace the initial
> next() made by yield-from.

It doesn't matter if there is only one use case, as long as it is a
common one. And we already have that: Greg Ewing's "refactoring".

Remember, Dave Beazley in his coroutine tutorial expresses doubts
about whether it is really that useful to use generators as
coroutines.

You are fighting a losing battle here, and it would be better if we
stopped short of trying to attain perfection, and instead accepted an
imperfect solution that may be sufficient, or may have to be extended
in the future. If your hypothetical use cases really become important
you can write another PEP.

> This is different from the close() issues we
> debated earlier, where there is a relatively simple workaround.  The full
> workaround for the "initial next()" issue is big, ugly, and slow.
>
> Anyway, I still hope the workaround won't be needed.

Not if you give up now.

>> 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.
>>
>
> No, I am not going to challenge you on this.   Once I have your answer to
> the questions at the beginning of this mail, I will try to adjust my future
> proposals accordingly.

Great.

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