Style question on recursive generators
aleaxit at yahoo.com
Wed Oct 20 09:12:59 CEST 2004
Greg Ewing <greg at cosc.canterbury.ac.nz> wrote:
> Alex Martelli wrote:
> > Dima Dorfman <d+pylist at nospamplease.trit.org> wrote:
> >> yield *other
> >>to mean:
> >> for x in other:
> >> yield x
> > Looks to me roughly equivalent to such proposals as 'yield from other';
> > not totally out of whack but IMHO not warranted.
> If it's a matter of whether a special syntax for this
> is justified, it might open the way for some kind of
> optimisation to bypass the overhead of the extra
What "extra" for-loop? Sorry, must be missing something here.
Anyway, the bytecode that idiom makes is something like:
3 LOAD_FAST 0 (other)
>> 7 FOR_ITER 10 (to 20)
10 STORE_FAST 1 (x)
13 LOAD_FAST 1 (x)
17 JUMP_ABSOLUTE 7
where of course  is to be replaced by the computation of 'other' by
whatever means. The pattern in 6..17 doesn't seem hard to recognize if
we want to optimize commonly occurring blocks of bytecode into something
faster -- assuming this IS commonly occurring, of course, and that there
is a worthwhile optimization (maybe into a new bytecode, or something).
But introducing special syntax just to replace the need for an
optimizer's looking into bytecode patterns leaves me a bit dubious.
Also, I think there may be other more common patterns to optimize with
higher priority/returns than this one (just guessing).
I wouldn't mind if 2.4->2.5 focused (besides the library) on
optimization (perhaps conditional on -O, which right now doesn't _do_
much;-) -- and peephole optimizing the bytecode looks like something
that might well be worthwhile. I know of attempts to do that in the
past, and as I recall they weren't very fruitful, but the internals have
changed enough since then that this might now be different.
More information about the Python-list