On 10/9/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Sometimes I miss the obvious. There's a *much*, *much* better place to store > the return value of a generator than on the StopIteration exception that it > raises when it finishes. Just save the return value in the *generator*. > > And then provide a method on generators that is the functional equivalent of: > > def result(): > # Finish the generator if it isn't finished already > for step in self: > pass > return self._result # Return the result saved when the block finished > > It doesn't matter that a for loop swallows the StopIteration exception any > more, because the return value is retrieved directly from the generator.
Actually, I don't like this at all. It harks back to earlier proposals where state was stored on the generator (e.g. PEP 288). > I also like that this interface could still be used even if the work of > getting the result is actually farmed off to a separate thread or process > behind the scenes. That seems an odd use case for generators, better addressed by creating an explicit helper object when the need exists. I bet that object will need to exist anyway to hold other information related to the exchange of information between threads (like a lock or a Queue). Looking at your example, I have to say that I find the trampoline example from PEP 342 really hard to understand. It took me several days to get it after Phillip first put it in the PEP, and that was after having reconstructed the same functionality independently. (I have plans to replace or augment it with a different set of examples, but haven't gotten the time. Old story...) I don't think that something like that ought to be motivating generator extensions. I also think that using a thread for async I/O is the wrong approach -- if you wanted to use threads shou should be using threads and you wouldn't be dealing with generators. There's a solution that uses select() which can handle as many sockets as you want without threads and without the clumsy polling ("is it ready yet? is it ready yet? is it ready yet?"). I urge you to leave well enough alone. There's room for extensions after people have built real systems with the raw material provided by PEP 342 and 343. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com