[Python-ideas] yiled-from restrictions [was: x=(yield from) confusion]

[Jacob Holm]

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.


- Jacob