Why don't generators execute until first yield?

[castironpi at gmail.com]

On May 7, 4:51 pm, Michael Torrie <torr... at gmail.com> 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.