On Thu, Mar 26, 2009 at 10:19 AM, P.J. Eby <p...@telecommunity.com> wrote: > At 10:56 AM 3/26/2009 +0000, Antoine Pitrou wrote: >> >> Guido van Rossum <guido <at> python.org> writes: >> > >> > That's stating it a little too strongly. Phillip has shown how with >> > judicious use of decorators and helper classes you can get a >> > reasonable approximation, and I think Twisted uses something like >> > this, so it's not just theory. I think the best you can do without new >> > syntax though is still pretty cumbersome and brittle, which is why I >> > have encouraged your PEP. >> >> It remains to be seen whether Twisted and other libraries (Kamaelia?) can >> benefit from this PEP. > > They don't get any new features, and would require (possibly significant) > changes in order to be able to take advantage of the syntax.
Well yes if you want to maintain backwards compatibility there wouldn't be any advantage. The point of the new syntax is clearly that (eventually) they can stop having their own wrappers, decorators and helpers (for this purpose). > And they *still* wouldn't be able to do away with their trampolines -- the > new trampolines would just be able to avoid the need for a generator stack, > if they previously had one to begin with. From your description, it sounds > like Twisted's version of this doesn't even use a stack. Whether yo need a trampoline or not depends on other needs of a framework. There is some clear low-hanging fruit for Greg's proposal where no trampoline or helpers are needed -- but where currently refactoring complex code containing many yield statements is cumbersome due to the nee to write each "subroutine" call as "for x in subroutine(): yield x" -- being able to replace this with "yield from subroutine()" is a conceptual advantage to me that is not proportional to the number of characters saved. > (Note: by "trampoline" I mean, "thing that processes yielded values and > manages the resumption of the generator", which need not be global. The > example trampoline I posted earlier is also implemented as a decorator, and > could be trivially extended via a lookup table to handle deferreds, delayed > calls, or whatever else you wanted it to support as yield targets.) -- --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
