[Python-Dev] Re: Graph exploration with generators
Kevin Jacobs
jacobs at penguin.theopalgroup.com
Wed Aug 20 11:53:47 EDT 2003
On Mon, 18 Aug 2003, David Eppstein wrote:
> In article <3F419D09.5070709 at ieee.org>,
> "Shane Holloway (IEEE)" <shane.holloway at ieee.org> wrote:
>
> > I assume this loss is due to restoring each context in the chain. (I
> > would need help verifying this assumption.)
> > What I would like to propose is a "yield *" type statement, where "yield
> > *collection" would have the equivalent
> > functionality of "for item in collection: yield item". The above example
> > would then appear as follows:
>
> It's been proposed before, with somewhat different syntax ("yield every"
> instead of "yield *"): http://tinyurl.com/kfvc
>
> The syntax alone doesn't help speed things up, but iirc Greg Ewing had
> some good ideas for doing this efficiently. I think the concensus was,
> though, that generators are so new that we haven't had enough experience
> to know what the best ways of using them are, so it would be premature
> to settle on chaining them this way.
99% of the "problem" can be taken care of by adding a relatively simple
optimization to the interpreter. It involves adding the necessary
book-keeping to propogate values yielded by a generator directly to the next
expression it is needed in, and conversely to return to the generator
directly when the next value is requested. Say we have a depth-N tree, then
for each leaf node, the interpreter must pass a value up to N-1 levels of
generators. If the values yielded are direct generator calls, then all N-1
of those yields can be elided. This allows "yield *" to be written
efficiently as a simple C-function, that is equivalent to this Python
generator:
def yield_star(iterable):
for i in iterable:
yield i
Interestingly enough, this same optimization can also be applied to return
expressions/values, and is related to tail-call optimizations done by
traditional compilers and functional-language interpreters. It is also very
much related to continuation-passing-style (CPS) transformations, which for
Python generators, have very tractable semantics.
Regards,
-Kevin
--
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (440) 871-6725 x 19 E-mail: jacobs at theopalgroup.com
Fax: (440) 871-6722 WWW: http://www.theopalgroup.com/
More information about the Python-Dev
mailing list