[Python-ideas] x=(yield from) confusion [was:Yet another alternative name for yield-from]
jh at improva.dk
Thu Apr 9 14:13:33 CEST 2009
Guido van Rossum wrote:
> On Wed, Apr 8, 2009 at 7:52 PM, Jacob Holm <jh at improva.dk> wrote:
>> 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,
> 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.
That rules out Gregs and my patches as well. They both need extra state
on the frame object to be able to implement yield-from in the first place.
>> 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.
In that case, I give up. There is no possible way to fix the "initial
next()" issue of yield-from without one or the other.
>> 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?
Then let me revisit my earlier statement that when close() catches a
StopIteration with a non-None value, it should either return it or raise
an exception. Since the value is not saved, a second close() will
neither be able to return it, nor raise a StopIteration with it.
Therefore I now think that raising a RuntimeError in that case is the
only right thing to do.
>>> 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".
I remain unconvinced that the "initial next()" issue isn't also a
problem for that use case, but I am not going to argue about this.
> Remember, Dave Beazley in his coroutine tutorial expresses doubts
> about whether it is really that useful to use generators as
> 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.
Looks to me like the battle is not so much losing as already lost, and
probably was from the start. I just wish I had understood that earlier.
One final suggestion I have is to make yield-from raise a RuntimeError
if used on a generator that already has a frame. That would a) open
some optimization possibilities, b) make it clear that the only intended
use is with a *fresh* generator or a non-generator iterable, and c)
allow us to change our minds about the initial next() later without
changing the semantics of working code.
>> 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.
Well, since I am giving up on fixing the "initial next()" issue in the
core, the workaround *will* be needed. Maybe not in the PEP, but
certainly as a recipe somewhere. If you don't mind, I will continue the
discussion about the details of such a workaround that Nick started a
couple of mails back in this thread.
>>> 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.
More information about the Python-ideas