Style question on recursive generators

[Jeff Epler]

Anyway, the bytecode that idiom makes is something like:

3 LOAD_FAST 0 (other)
6 GET_ITER
10 STORE_FAST 1 (x)
13 LOAD_FAST 1 (x)
16 YIELD_VALUE
17 JUMP_ABSOLUTE 7

I think that the other thing the compiler must recognize, beyond this
sequence, is that "x" is dead below the loop (no longer used, or stored
to before the next use).

On the other hand, I guess the new YIELD_VALUES opcode could leave the
last value on the top of the stack, replacing this sequence with
LOAD_FAST 0 (other)
GET_ITER
YIELD_VALUES
STORE_FAST 1 (x)
I was imagining that YIELD_VALUES would not put anything on the stack,
if it was used to implement a new 'yield from'/'yield *' statement.

Jeff

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFBdmt5Jd01MZaTXX0RAnPIAJ9DC6O9Qc6SyZXKvL2AcGDTkfFdqACfQaiB
tQ8tt5rgc4Fb5ZJ5ZuM1ekE=
=8d2A
-----END PGP SIGNATURE-----

 

[Carlos Ribeiro]

I think that the other thing the compiler must recognize, beyond this
sequence, is that "x" is dead below the loop (no longer used, or stored
to before the next use).

I've read somewhere else that there are plans to make the loop
variable to be limited in scope _to the loop only. Not sure about the
details though.

On the other hand, I guess the new YIELD_VALUES opcode could leave the
last value on the top of the stack, replacing this sequence with
LOAD_FAST 0 (other)
GET_ITER
YIELD_VALUES
STORE_FAST 1 (x)
I was imagining that YIELD_VALUES would not put anything on the stack,
if it was used to implement a new 'yield from'/'yield *' statement.

As per your own observation, the STORE_FAST above is not needed, now
that the loop on 'x' was removed. The removal of the bytecode-level
loop (the JUMP_ABSOLUTE bytecode) would probably give some measurable
performance gain. But -- again -- it all depends on whether such idiom
is common enough.

--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: (e-mail address removed)
mail: (e-mail address removed)

 

[Terry Reedy]

I've read somewhere else that there are plans to make the loop
variable to be limited in scope _to the loop only. Not sure about the
details though.

I believe that might have happened already for the loop var *within* a list
comprehension, and maybe within a generator expression (easy to test). As
I remember, the idea has been explicitly rejected for the loop var in for
statements, which will remain compatible with equivalent while loops with
explicitly assigned vars.

Terry J. Reedy