Opposite of yield?

[Peter Hansen]

achrist at easystreet.com wrote:
> 
> Peter Hansen wrote:
> >
> >
> > Queue.Queue.get() ...
> >
> 
> That looks good.  But that needs a thread to block, right?

Yep.

> A generator manages to run without being a thread (at least
> overtly).  If we have the suck() statement, we also need
> something that's the opposite of a generator (a Sucker?)
> and something that's the opposite of an iterator (a Suckee?).
> I'm starting to get an idea why this is completely not all
> there.
> 
> The main question this raises is "How lightweight are threads?"
> Can I program with dozens or hundreds of python threads in a
> program (for example under Windows) and not notice that this is
> an inefficient or inept coding style?

The real question might be why would you want to?

If you don't want a thread, but you want something which takes
input from elsewhere and does some processing, then returns 
control to some other place until more data is available (which
is what one might assume if threads aren't good for you), there
is already a convenient solution: the subroutine.  ;-)

Seriously, what's the requirement driving the need for this?
(I suspect Erik Max's answer is still what you need, and you
misunderstand the nature of what he was suggesting, but if you'll
explain the specific case you have in mind we'll know for sure.)

-Peter