Arnaud Delobelle wrote:
>> * I don't think you can handle 'close' in accordance with the PEP,
>> and fixing this does not look easy.
>
> I haven't thought about this - unfortunately probably won't have time
> till next weekend :(
:(
>> * It seems like in your version, you only gain when only the
>> outermost generator is decorated. (You conveniently modified the
>> testing code to only decorate with co *after* building the long
>> chain). You need to have *all* generators using FROM decorated, or
>> disaster will strike as soon as someone calls next on one of the
>> intermediate generators.
>>
>
> I don't think this is really a problem. If yield-from was in the
> language, this 'decoration' could be added automatically at
> compile-time. I haven't really thought about it in detail however :)
Agreed, but the purpose of the test is to see how it *would* behave if
the 'decoration' happened at compile time. Stripping it off will only
hide problems, such as the fact that there is no speed benefit at all...
>
>>> So the turning point is a depth of 10, after which my implementation
>>> wins. At a depth of 90, cochild is about 10 times faster than child.
>> As could be expected, since you also have O(1) in this case. However,
>> if you decorate all the generators in the chain you lose no matter
>> what N is... Most of the speed difference between our versions is
>> probably due to the fact that I am using classes instead of
>> generators to allow me to have everything decorated, and to handle
>> some more convoluted cases as well.
>>
>
> But decorating each generator would defeat the purpose! I guess one
> way to find out would be to reimplement it with a class - see below!
And what purpose is that, if I might ask? My two purposes were to a)
test my algorithm for speeding up arbitrarily complex cases, and b) have
a way to play with the "yield from" concept as specified in the PEP. It
seems that your original purpose was similar to b). My claim is that
using your 'FROM' outside a generator decorated with your 'co' has no
equivalent in the PEP and might be a bad idea, and I gave an example
where this gives a bad/unexpected result.
>>>
>>> I don't know if my implementation behaves well with other examples
>>> you have in mind, I would like to know!
>>>
>> I'll write a few more tests tonight so you can see the kind of
>> problems I am looking at.
>
> That would be good. If I think my method can handle them, then I might
> reimplement it with a class - it wouldn't take very long but I have
> very little time at the moment!
>
> Thanks,
>
It looks like it might not be tonight after all. I'll try to get to it
some time during this week.
Best regards
Jacob
