Re: Queue enhancement suggestion

On 2007-04-18, Hendrik van Rooyen <[EMAIL PROTECTED]> wrote: > "Antoon Pardon" <[EMAIL PROTECTED]> wrote: > > >> The problem is that sometimes the gui thread has something to show >> too. With the added problem that the code wanting to show something >> doesn't know when it is executing the gui th

Re: Queue enhancement suggestion

On 2007-04-17, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: > On 17 Apr 2007 14:32:01 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote: >>On 2007-04-17, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: >>> On 17 Apr 2007 13:32:52 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote: On 2007-04-17, Hendrik

Re: Queue enhancement suggestion

"Antoon Pardon" <[EMAIL PROTECTED]> wrote: > The problem is that sometimes the gui thread has something to show > too. With the added problem that the code wanting to show something > doesn't know when it is executing the gui thread or an other. So > it is very difficult to avoid the gui thread

Re: Queue enhancement suggestion

> The problem is that sometimes the gui thread has something to show > too. With the added problem that the code wanting to show something > doesn't know when it is executing the gui thread or an other. So > it is very difficult to avoid the gui thread putting things on the > queue. But since the g

Re: Queue enhancement suggestion

On 17 Apr 2007 14:32:01 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote: >On 2007-04-17, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: >> On 17 Apr 2007 13:32:52 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote: >>>On 2007-04-17, Hendrik van Rooyen <[EMAIL PROTECTED]> wrote: >>> [snip] >> Not sure I

Re: Queue enhancement suggestion

On 2007-04-17, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: > On 17 Apr 2007 13:32:52 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote: >>On 2007-04-17, Hendrik van Rooyen <[EMAIL PROTECTED]> wrote: >> [snip] > >>> Not sure I understand this - it sounds vaguely incestous to me. >>> I normally use a

Re: Queue enhancement suggestion

On 17 Apr 2007 13:32:52 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote: >On 2007-04-17, Hendrik van Rooyen <[EMAIL PROTECTED]> wrote: > [snip] >> Not sure I understand this - it sounds vaguely incestous to me. >> I normally use a GUI with two queues, one for input, one for >> output, to two thread

Re: Queue enhancement suggestion

On 2007-04-17, Hendrik van Rooyen <[EMAIL PROTECTED]> wrote: > > "Antoon Pardon" <[EMAIL PROTECTED]> wrote: > >> On 2007-04-17, Hendrik van Rooyen <[EMAIL PROTECTED]> wrote: >> > "Antoon Pardon" <[EMAIL PROTECTED]> wrote: >> > >> > >> >> The problem is this doesn't work well if you have multiple pr

Re: Queue enhancement suggestion

"Antoon Pardon" <[EMAIL PROTECTED]> wrote: > On 2007-04-17, Hendrik van Rooyen <[EMAIL PROTECTED]> wrote: > > "Antoon Pardon" <[EMAIL PROTECTED]> wrote: > > > > > >> The problem is this doesn't work well if you have multiple producers. > >> One producer can be finished while the other is still pu

Re: Queue enhancement suggestion

On 2007-04-17, Hendrik van Rooyen <[EMAIL PROTECTED]> wrote: > "Antoon Pardon" <[EMAIL PROTECTED]> wrote: > > >> The problem is this doesn't work well if you have multiple producers. >> One producer can be finished while the other is still putting values >> on the queue. >> >> The solution I have b

Re: Queue enhancement suggestion

On 2007-04-17, Paul Rubin wrote: > Antoon Pardon <[EMAIL PROTECTED]> writes: >> The problem is this doesn't work well if you have multiple producers. >> One producer can be finished while the other is still putting values >> on the queue. > > Right, you'd wait for all the producers to finish, then

Re: Queue enhancement suggestion

"Antoon Pardon" <[EMAIL PROTECTED]> wrote: > The problem is this doesn't work well if you have multiple producers. > One producer can be finished while the other is still putting values > on the queue. > > The solution I have been thinking on is the following. > > Add an open and close operation.

Re: Queue enhancement suggestion

Antoon Pardon <[EMAIL PROTECTED]> writes: > The problem is this doesn't work well if you have multiple producers. > One producer can be finished while the other is still putting values > on the queue. Right, you'd wait for all the producers to finish, then finish the queue: for p in producer_th

Re: Queue enhancement suggestion

Jean-Paul Calderone <[EMAIL PROTECTED]> writes: > Instead of putting multiple sentinels, just pre-construct the iterator > object. > work = iter(q.get, sentinel) > Re-use the same iterator in each thread, and you'll get the behavior > you're after. Whaaat??? Can I do that? It looks l

Re: Queue enhancement suggestion

On 15 Apr 2007 23:12:34 -0700, Paul Rubin <"http://phr.cx"@nospam.invalid> wrote: >I'd like to suggest adding a new operation > > Queue.finish() > >This puts a special sentinel object on the queue. The sentinel >travels through the queue like any other object, however, when >q.get() encounters

Re: Queue enhancement suggestion

On Apr 15, 11:12 pm, Paul Rubin wrote: > I'd like to suggest adding a new operation > >Queue.finish() > > This puts a special sentinel object on the queue. The sentinel > travels through the queue like any other object, however, when > q.get() encounters the sentinel

Re: Queue enhancement suggestion

On 2007-04-16, Paul Rubin wrote: > I'd like to suggest adding a new operation > >Queue.finish() > > This puts a special sentinel object on the queue. The sentinel > travels through the queue like any other object, however, when > q.get() encounters the sentinel, it raises StopIteration instea

Re: Queue enhancement suggestion

Paul Rubin wrote: > I'd like to suggest adding a new operation > >Queue.finish() > > This puts a special sentinel object on the queue. The sentinel > travels through the queue like any other object, however, when > q.get() encounters the sentinel, it raises StopIteration instead > of return