[Python-ideas] yiled-from restrictions [was: x=(yield from) confusion]
jh at improva.dk
Thu Apr 9 19:50:05 CEST 2009
Jim Jewett wrote:
> On 4/9/09, Jacob Holm <jh at improva.dk> wrote:
>> 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.
> Well, to do it efficiently anyhow... but it doesn't need to be
> user-visible, which is why I asked for clarification.
Sure, if you change the patch to emit the same byte codes as the
expansion in the PEP would, you can get by without. Of course that
would increase the overhead of each delegated next(), send() or throw()
call by at least one order of magnitude. (That is based on actual
testing, where I compared my implementation of yield-from with a yield
in a simple for-loop. Since the PEP expansion is more complex than a
for-loop, I expect the overhead to be somewhat greater).
>> 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 prevent priming the generator. It would also prevent
> "handled the header lines already; pass the data records off to a
> different routine."
Yes, but since there is no sane way the this can work in the current
proposal, I would rather raise a RuntimeError.
More information about the Python-ideas