[Joachim Koenig-Baltes]
> > My use case for this is a directory tree walking generator that
> > yields all the files including the directories in a depth first
manner.
> > If a directory satisfies a condition (determined by the caller) the
> > generator shall not descend into it.
> >
> > Something
On Fri, 2005-06-17 at 13:53, Joachim Koenig-Baltes wrote:
[...]
> My use case for this is a directory tree walking generator that
> yields all the files including the directories in a depth first manner.
> If a directory satisfies a condition (determined by the caller) the
> generator shall not des
Guido van Rossum wrote:
>
>However, I can see other uses for looping over a sequence using a
>generator and telling the generator something interesting about each
>of the sequence's items, e.g. whether they are green, or should be
>printed, or which dollar value they represent if any (to make up a
At 11:29 AM 6/17/2005 +0100, Gustavo J. A. M. Carneiro wrote:
> In conjunction with pseudo-threads, I think a "python main loop"
>implementation is fundamental. Such main loop with permit the programmer
>to register callbacks for events, such as timeouts, IO conditions, idle
>tasks, etc., such a
On Fri, 2005-06-17 at 00:43, Raymond Hettinger wrote:
> Let me go on record as a strong -1 for "continue EXPR". The for-loop is
> our most basic construct and is easily understood in its present form.
> The same can be said for "continue" and "break" which have the added
> advantage of a near zer
Hello,
I found your paper very interesting. I have also written a very
minimalistic white paper, mostly aimed at the PyGTK community, with a
small module for pseudo-threads using python generators:
http://www.gnome.org/~gjc/gtasklet/gtasklets.html
I don't have time to follow this
At 08:24 PM 6/16/2005 -0400, Raymond Hettinger wrote:
> As a further benefit, using
>attributes was a natural approach because that same technique has long
>been used with classes (so no new syntax was needed and the learning
>curve was zero).
On Friday 17 Jun 2005 02:53, Phillip J. Eby wrote:
> U
[Raymond]
> Let me go on record as a strong -1 for "continue EXPR". The for-loop is
> our most basic construct and is easily understood in its present form.
> The same can be said for "continue" and "break" which have the added
> advantage of a near zero learning curve for people migrating from ot
[Phillip]
> > I also personally don't care about the new continue feature,
> > so I could do without for-loop alteration too.
[Guido]
> I do like "continue EXPR" but I have to admit I haven't even tried to
> come up with examples -- it may be unnecessary. As Phillip says, yield
> expressions an
At 12:07 AM 6/17/2005 -0400, Phillip J. Eby wrote:
> def schedule_coroutine(geniter, *arg):
> def resume():
> value = geniter.next(*arg)
> if value is not None:
> schedule_coroutine(value)
> reactor.callLater(0, resume)
Oops. I jus
At 08:03 PM 6/16/2005 -0700, Guido van Rossum wrote:
>Someone should really come up with some realistic coroutine examples
>written using PEP 342 (with or without "continue EXPR").
How's this?
def echo(sock):
while True:
try:
data = yield nonblocking_read(s
On 6/16/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Phillip]
> > I could definitely go for dropping __next__ and the next() builtin from PEP
> > 342, as they don't do anything extra. I also personally don't care about
> > the new continue feature, so I could do without for-loop alteration
At 10:26 PM 6/16/2005 -0400, Raymond Hettinger wrote:
>288 was brought out of retirement a few months ago. Guido hated every
>variation of argument passing and frequently quipped that data passing
>was trivially accomplished though mutable arguments to a generator,
>through class based iterators,
[Phillip]
> I could definitely go for dropping __next__ and the next() builtin
from
> PEP
> 342, as they don't do anything extra. I also personally don't care
about
> the new continue feature, so I could do without for-loop alteration
> too. I'd be perfectly happy passing arguments to next() exp
At 08:24 PM 6/16/2005 -0400, Raymond Hettinger wrote:
>Looking back at the history of 288, generator attributes surfaced only
>in later drafts. In the earlier drafts, the idea for passing arguments
>to and from running generators used an argument to next() and a return
>value for yield. If this s
15 matches
Mail list logo