Greg Ewing <greg.ewing@...> writes:
Using a specialised syntax opens up possibilities for optimisation when there is a long chain of generators. Such chains can arise, for instance, when recursively traversing a tree structure. The overhead of passing ``next()`` calls and yielded values down and up the chain can cause what ought to be an O(n) operation to become O(n\*\*2).
It should be relatively easy to avoid O(n**2) behaviour when traversing a tree, so I find this argument quite artificial.
It has been suggested that some mechanism other than ``return`` in the subgenerator should be used to establish the value returned by the ``yield from`` expression. However, this would interfere with the goal of being able to think of the subgenerator as a suspendable function, since it would not be able to return values in the same way as other functions.
The problem I have with allowing "return" in generators is that it makes things much more confusing (try explaining a beginner that he has the right to return a value from a generator but the value can't be retrieved through any conventional means: a "for" loop, a builtin function or method consuming the iterator, etc.). I can imagine it being useful in some Twisted-like situation: the inner generator would first yield a bunch of intermediate Deferreds to wait for the completion of some asynchronous thing, and then return the final Deferred for its caller to retrieve. But I think it wouldn't need the "yield from" construct to function, just the "return" thing. Regards Antoine.