[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
PEP 288 is now withdrawn. The generator exceptions portion is subsumed
by PEP 343, and the generator attributes portion never garnered any
support.
The fate of generator attributes is interesting vís-a-vís PEP 342. The
motivation was always related to supporting advanced generator uses such
as e
16 matches
Mail list logo
