[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 other
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:
Ugh.
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
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 zero
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 as one
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
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 vs-a-vs PEP 342. The
motivation was always related to supporting advanced generator uses such
as
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
[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()
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, or
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
too.
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
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 just
[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 and
14 matches
Mail list logo
