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