Opposite of yield?

**Paul Rubin** · Jul 18 '05, 02:25 AM

Re: Opposite of yield?

achrist@easystr eet.com writes:[color=blue]
> The yield statement looks to be a big step toward some kind of
> lightweight concurrency-oriented programming in python. Is there
> any similarly nice way to do the opposite of yield, just sit around
> (perhaps in the middle of a loop) and wait until some other routine
> (unknown to the waiting module) hurls a value in?
>
> If this is not implemented now, is there any chance that it's on the
> list of things to come?[/color]

Not much chance. Even Stackless can't do that any more, if I
understand correctly.

**Erik Max Francis** · Jul 18 '05, 02:25 AM

Re: Opposite of yield?

achrist@easystr eet.com wrote:
[color=blue]
> The yield statement looks to be a big step toward some kind of
> lightweight concurrency-oriented programming in python. Is there
> any similarly nice way to do the opposite of yield, just sit around
> (perhaps in the middle of a loop) and wait until some other routine
> (unknown to the waiting module) hurls a value in?[/color]

Yep:

generator.next( )

--
Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ Dead men have no victory.
\__/ Euripides

**Bob Gailer** · Jul 18 '05, 02:25 AM

Re: Opposite of yield?

At 01:40 PM 9/10/2003, achrist@easystr eet.com wrote:

[color=blue]
>The yield statement looks to be a big step toward some kind of
>lightweight concurrency-oriented programming in python. Is there
>any similarly nice way to do the opposite of yield, just sit around
>(perhaps in the middle of a loop) and wait until some other routine
>(unknown to the waiting module) hurls a value in?[/color]

Sounds like a task for a thread that sleeps a while then checks for the data.

Also reminiscent (a long time ago) someone proposed a COME FROM statement
for FORTRAN to be the inverse of GO TO.

Perhaps a new Python statement "suck"?

Bob Gailer
bgailer@alum.rp i.edu
303 442 2625

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.506 / Virus Database: 303 - Release Date: 8/1/2003

**Dave Benjamin** · Jul 18 '05, 02:25 AM

Re: Opposite of yield?

"Bob Gailer" <bgailer@alum.r pi.edu> wrote in message
news:mailman.10 63223955.7295.p ython-list@python.org ...[color=blue]
> At 01:40 PM 9/10/2003, achrist@easystr eet.com wrote:[color=green]
> >The yield statement looks to be a big step toward some kind of
> >lightweight concurrency-oriented programming in python. Is there
> >any similarly nice way to do the opposite of yield, just sit around
> >(perhaps in the middle of a loop) and wait until some other routine
> >(unknown to the waiting module) hurls a value in?[/color]
>
> ...
>
> Perhaps a new Python statement "suck"?[/color]

Oh come on, now, just because Java does it...

**Peter Hansen** · Jul 18 '05, 02:25 AM

Re: Opposite of yield?

achrist@easystr eet.com wrote:[color=blue]
>
> The yield statement looks to be a big step toward some kind of
> lightweight concurrency-oriented programming in python. Is there
> any similarly nice way to do the opposite of yield, just sit around
> (perhaps in the middle of a loop) and wait until some other routine
> (unknown to the waiting module) hurls a value in?
>
> If this is not implemented now, is there any chance that it's on the
> list of things to come?[/color]

Queue.Queue.get () ...

-Peter

**Christos TZOTZIOY Georgiou** · Jul 18 '05, 02:25 AM

Re: Opposite of yield?

On Wed, 10 Sep 2003 12:40:37 -0700, rumours say that
achrist@easystr eet.com might have written:
[color=blue]
>The yield statement looks to be a big step toward some kind of
>lightweight concurrency-oriented programming in python. Is there
>any similarly nice way to do the opposite of yield, just sit around
>(perhaps in the middle of a loop) and wait until some other routine
>(unknown to the waiting module) hurls a value in?[/color]

Almost. Use a Queue.Queue() and threads. That is, some other thread(s)
does/do .put() and you wait with a .get().
Without threads, I don't believe there is such a mechanism, not even in
Stackless, as Paul said.
[color=blue]
>If this is not implemented now, is there any chance that it's on the
>list of things to come?[/color]

I believe such a chance would be a candidate for dietary products
advertising (that is, slim :).
--
TZOTZIOY, I speak England very best,
Microsoft Security Alert: the Matrix began as open source.

**Christos TZOTZIOY Georgiou** · Jul 18 '05, 02:25 AM

Re: Opposite of yield?

On Wed, 10 Sep 2003 20:19:35 GMT, rumours say that "Dave Benjamin"
<dave@3dex.co m> might have written:
[color=blue][color=green]
>> Perhaps a new Python statement "suck"?[/color]
>
>Oh come on, now, just because Java does it...[/color]

QOTW +1 :)
--
TZOTZIOY, I speak England very best,
Microsoft Security Alert: the Matrix began as open source.

**achrist@easystreet.com** · Jul 18 '05, 02:25 AM

Re: Opposite of yield?

Peter Hansen wrote:[color=blue]
>
>
> Queue.Queue.get () ...
>[/color]

That looks good. But that needs a thread to block, right?
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?

Al

**achrist@easystreet.com** · Jul 18 '05, 02:25 AM

Re: Opposite of yield?

Erik Max Francis wrote:[color=blue]
>
>
> Yep:
>
> generator.next( )
>[/color]

This style supports only output-driven processes. The generator,
being on the input side, is always the server, and the output
side is always the client. It doesn't fit the situation where the
input is heterogeneous and input has to get spewed in several
directions, depending on its content.

Al

**Peter Hansen** · Jul 18 '05, 02:25 AM

Re: Opposite of yield?

achrist@easystr eet.com wrote:[color=blue]
>
> Peter Hansen wrote:[color=green]
> >
> >
> > Queue.Queue.get () ...
> >[/color]
>
> That looks good. But that needs a thread to block, right?[/color]

Yep.
[color=blue]
> 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?[/color]

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

**Chris Liechti** · Jul 18 '05, 02:25 AM

Re: Opposite of yield?

achrist@easystr eet.com wrote in news:3F5F95B9.A 8CB5786@easystr eet.com:
[color=blue]
> Peter Hansen wrote:[color=green]
>>
>>
>> Queue.Queue.get () ...
>>[/color]
>
> That looks good. But that needs a thread to block, right?[/color]

yes
[color=blue]
> 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.[/color]

basicaly you poll every generator (or more precicly "iterable" as that is
what a generator returns), one after the other... enjoy the link below.
[color=blue]
> 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?[/color]

this one is for you :-)

http://www-106.ibm.com/developerworks/linux/library/l-pythrd.html

you wont get happy with hundrets of native threads, but with the light ones
from above you can have thousands...

generaly you will find interesting stuff here (one line):

http://www-

106.ibm.com/developerworks/views/linux/articles.jsp?so rt_order=desc&e xpand=
&sort_by=Date&s how_abstract=tr ue&view_by=Sear ch&search_by=ch arming+python%3
A

chris
--
Chris <cliechti@gmx.n et>

**Bengt Richter** · Jul 18 '05, 02:25 AM

Re: Opposite of yield?

On Wed, 10 Sep 2003 14:39:14 -0700, achrist@easystr eet.com wrote:
[color=blue]
>Erik Max Francis wrote:[color=green]
>>
>>
>> Yep:
>>
>> generator.next( )
>>[/color]
>
>This style supports only output-driven processes. The generator,
>being on the input side, is always the server, and the output
>side is always the client. It doesn't fit the situation where the
>input is heterogeneous and input has to get spewed in several
>directions, depending on its content.
>
>[/color]
Could you make some fantasy-code to illustrate what you mean?

Regards,
Bengt Richter

**Stuart D. Gathman** · Jul 18 '05, 02:25 AM

Re: Opposite of yield?

On Wed, 10 Sep 2003 17:39:14 -0400, achrist wrote:
[color=blue]
> Erik Max Francis wrote:[color=green]
>>
>> Yep:
>>
>> generator.next( )
>>[/color]
> This style supports only output-driven processes. The generator, being
> on the input side, is always the server, and the output side is always
> the client. It doesn't fit the situation where the input is
> heterogeneous and input has to get spewed in several directions,
> depending on its content.[/color]

It does if you add a dispatcher framework. There is a python project for
just such a framework, but I can't remember the name. The idea is dirt
simple, but the implementation gets knarly with exceptions and such.

Found it - Charming Python

http://www-106.ibm.com/developerworks/linux/library/l-pythrd.html

**Erik Max Francis** · Jul 18 '05, 02:25 AM

Re: Opposite of yield?

achrist@easystr eet.com wrote:
[color=blue]
> This style supports only output-driven processes. The generator,
> being on the input side, is always the server, and the output
> side is always the client. It doesn't fit the situation where the
> input is heterogeneous and input has to get spewed in several
> directions, depending on its content.[/color]

The distinction you're making is push vs. pull processing. To get what
you want, you should use some sort of asynchronous mechanism with
synchronization when data is transferred. Threading with the use of the
Queue module comes to mind immediately. Other forms of asynchronous
processing are certainly possible, as well.

That being said, calling the next method of a generator _is_ the obvious
inverse process of a generator yielding a value.

--
Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ Forever we / Infinitely
\__/ Sandra St. Victor

Opposite of yield?

Opposite of yield?

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment