On May 7, 4:51 pm, Michael Torrie <[EMAIL PROTECTED]> wrote: > Martin Sand Christensen wrote: > > Why don't > > generators follow the usual eager evaluation semantics of Python and > > immediately execute up until right before the first yield instead? > > A great example of why this behavior would defeat some of the purpose of > generators can be found in this amazing PDF presentation: > > http://www.dabeaz.com/generators/Generators.pdf > > > Giving generators special case semantics for no good reason is a really > > bad idea, so I'm very curious if there is a good reason for it being > > this way. With the current semantics it means that errors can pop up at > > unexpected times rather than the code failing fast. > > Most assuredly they do have good reason. Consider the cases in the PDF > I just mentioned. Building generators that work on the output of other > generators allows assembling entire pipelines of behavior. A very > powerful feature that would be impossible if the generators had the > semantics you describe. > > If you want generators to behave as you suggest they should, then a > conventional for x in blah approach is likely the better way to go. > > I use a generator anytime I want to be able to iterate across something > that has a potentially expensive cost, in terms of memory or cpu, to do > all at once.
The amount of concentration you can write in a program in a sitting (fixed amount of time) is kind of limited. Sounds like @greedy was the way to go. The recall implementation may have a short in the future, but isn't functools kind of full? Has wraptools been written? Is it any different? Naming for @greedy also comes to question. My humble opinion muscles glom on to @early vs. @late; @yieldprior; @dropfirst; @cooperative. Thesaurus.com adds @ahead vs. @behind. -- http://mail.python.org/mailman/listinfo/python-list