Style question on recursive generators

[Carlos Ribeiro]

On Mon, 18 Oct 2004 16:27:43 +0200, Alex Martelli <aleaxit at yahoo.com> wrote:
> Carlos Ribeiro <carribeiro at gmail.com> wrote:
>    ...
> > Yes, that's a good point, and it's one of the reasons I tend to prefer
> > the generator now. But anyway, it's just me, or does the 'chained
> > yield' look ugly to someone else? It may be just a question of getting
> > used to it, but nevertheless it's bugging me...
> 
> I'm not sure why it should look ugly to you.  What alternatives would
> you consider non-ugly for the common (in any generator) idiom:
>     for x in y: yield x
> ?
> 
> Perhaps some syntax hack such as a new statement keyword 'yieldall'
> where the above idiom could be expressed as
>     yieldall y
> ?  Or some other syntax hack such as 'yield<<y', or 'yield from y',
> ditto?  Personally, it would seem to me that such special syntax would
> be just one more bit of Python to learn, without substantial benefits,
> but that's because I see nothing ugly in today's idiom -- it does just
> what it says, plainly and unpretentiously...

Generally speaking, new keywords hardly solve any problem; in fact,
they create new problems of their own :-) In this case, my main gripe
is that the code doesn't read as naturally as the simple recursive
version, because of the double for loop. Its also strange because I
often have to stop and think, "what am I yielding now". For deeply
nested recursive cases there is also the feeling that the yield chain
may prove to be a performance dog, but that's should not be the main
point here anyway.

I have a strange idea in the back of my mind that tells me that a
possible solution would be to have any of the nested yields to
immediately return the result to the original caller. In this case, I
would write my code this way:

def walk(self):
   """generator-based recursive tree traversal"""
   yield child
   for child in childs:
        transfer child.walk()

It's quite weird -- a generator plus a direct flow-of-execution
transfer. It's not a goto, its not a co-routine... It requires a new
keyword ('transfer', in this case), which _is_ a real problem --
something like this can't be lightly proposed. In this case, it's just
a thought experiment, at this point; nothing serious, and far from a
proposal.

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: carribeiro at gmail.com
mail: carribeiro at yahoo.com