I've written a PEP about this topic. It's PEP 340: Anonymous Block
Statements (http://python.org/peps/pep-0340.html).
Some highlights:
- temporarily sidestepping the syntax by proposing 'block' instead of 'with'
- __next__() argument simplified to StopIteration or ContinueIteration instance
-
Hi.
I hope you don't mind another proposal. Please feel free to tear it apart.
A limitation of both Ruby's block syntax and the new PEP 340 syntax is
the fact that they don't allow you to pass in more than a single
anonymous block parameter. If Python's going to add anonymous blocks,
shouldn't
Paul Svensson wrote:
You're not mentioning scopes of local variables, which seems to be
the issue where most of the previous proposals lose their balance
between hairy and pointless...
My syntax is just sugar for nested defs. I assumed the scopes of local
variables would be identical when
Guido van Rossum wrote:
I've written a PEP about this topic. It's PEP 340: Anonymous Block
Statements (http://python.org/peps/pep-0340.html).
Some highlights:
- temporarily sidestepping the syntax by proposing 'block' instead of 'with'
- __next__() argument simplified to StopIteration or
Guido van Rossum wrote:
I've written a PEP about this topic. It's PEP 340: Anonymous Block
Statements (http://python.org/peps/pep-0340.html).
Some highlights:
- temporarily sidestepping the syntax by proposing 'block' instead of 'with'
- __next__() argument simplified to StopIteration or
Jim Fulton [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]:
Guido van Rossum wrote:
I've written a PEP about this topic. It's PEP 340: Anonymous Block
Statements (http://python.org/peps/pep-0340.html).
Some observations:
1. It looks to me like a bare return or a return with an EXPR3
Jim Fulton wrote:
Duncan Booth wrote:
Jim Fulton [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]:
Guido van Rossum wrote:
I've written a PEP about this topic. It's PEP 340: Anonymous Block
Statements (http://python.org/peps/pep-0340.html).
Some observations:
1. It looks to me like a bare return
Jim Fulton [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]:
No, the return sets a flag and raises StopIteration which should make
the iterator also raise StopIteration at which point the real return
happens.
Only if exc is not None
The only return in the pseudocode is inside if exc is
At 12:30 AM 4/27/05 -0700, Guido van Rossum wrote:
I've written a PEP about this topic. It's PEP 340: Anonymous Block
Statements (http://python.org/peps/pep-0340.html).
Some highlights:
- temporarily sidestepping the syntax by proposing 'block' instead of 'with'
- __next__() argument simplified to
Phillip J. Eby wrote:
This interest is unrelated to anonymous blocks in any case; it's about
being able to simulate lightweight pseudo-threads ala Stackless, for use
with Twisted. I can do this now of course, but yield expressions as
described in PEP 340 would eliminate the need for the
Jason Diamond [EMAIL PROTECTED] wrote:
Paul Svensson wrote:
You're not mentioning scopes of local variables, which seems to be
the issue where most of the previous proposals lose their balance
between hairy and pointless...
My syntax is just sugar for nested defs. I assumed the
Guido van Rossum [EMAIL PROTECTED] wrote:
I've written a PEP about this topic. It's PEP 340: Anonymous Block
Statements (http://python.org/peps/pep-0340.html).
Some highlights:
- temporarily sidestepping the syntax by proposing 'block' instead of 'with'
- __next__() argument simplified
I would think that the relevant psuedo-code should look more like:
except StopIteration:
if ret:
return exc
if exc is not None:
raise exc # XXX See below
break
Thanks! This was a bug in
On 4/27/05, Guido van Rossum [EMAIL PROTECTED] wrote:
I've written a PEP about this topic. It's PEP 340: Anonymous Block
Statements (http://python.org/peps/pep-0340.html).
So block-statements would be very much like for-loops, except:
(1) iter() is not called on the expression
(2) the fact
Your code for the translation of a standard for loop is flawed. From
the PEP:
for VAR1 in EXPR1:
BLOCK1
else:
BLOCK2
will be translated as follows:
itr = iter(EXPR1)
arg = None
while True:
try:
Folks,
There's been a lot of talk lately about changes to the ZipFile
module... Along with people stating that there are few real life
applications for it
Here's a small gift...
A Quick Backup utility for your files
Example:
that we are having this discussion at all seems a signal that the
semantics are likely too subtle.
I feel like we're quietly, delicately tiptoeing toward continuations...
___
Python-Dev mailing list
Python-Dev@python.org
Guido van Rossum [EMAIL PROTECTED] wrote:
Ouch. Another bug in the PEP. It was late. ;-)
The finally: should have been except StopIteration: I've updated
the PEP online.
Unless it is too early for me, I believe what you wanted is...
itr = iter(EXPR1)
arg = None
Guido van Rossum wrote:
I've written a PEP about this topic. It's PEP 340: Anonymous Block
Statements (http://python.org/peps/pep-0340.html).
Some highlights:
- temporarily sidestepping the syntax by proposing 'block' instead of 'with'
- __next__() argument simplified to StopIteration or
[Phillip Eby]
Very nice. It's not clear from the text, btw, if normal exceptions can be
passed into __next__, and if so, whether they can include a traceback. If
they *can*, then generators can also be considered co-routines now, in
which case it might make sense to call blocks coroutine
I feel like we're quietly, delicately tiptoeing toward continuations...
No way we aren't. We're not really adding anything to the existing
generator machinery (the exception/value passing is a trivial
modification) and that is only capable of 80% of coroutines (but it's
the 80% you need most
On 4/27/05, Guido van Rossum [EMAIL PROTECTED] wrote:
As long as I am BDFL Python is unlikely to get continuations -- my
head explodes each time someone tries to explain them to me.
You just need a safety valve installed. It's outpatient surgery, don't worry.
--david
At 01:27 PM 4/27/05 -0700, Guido van Rossum wrote:
[Phillip Eby]
Very nice. It's not clear from the text, btw, if normal exceptions can be
passed into __next__, and if so, whether they can include a traceback. If
they *can*, then generators can also be considered co-routines now, in
which
Guido writes:
You mean like this?
if x 0:
...normal case...
elif y 0:
abnormal case...
else:
...edge case...
You have guts to call that bad style! :-)
Well, maybe, but this:
if x == 1:
do_number_1()
elif x == 2:
[Guido]
I'm not sure what the relevance of including a stack trace would be,
and why that feature would be necessary to call them coroutines.
[Phillip]
Well, you need that feature in order to retain traceback information when
you're simulating threads with a stack of generators. Although you
Michael Chermside wrote:
if x == 1:|if condition_1:
do_1() |y = 1
elif x == 2: |elif condition_2:
do_2() |y = 2
elif x == 3: |elif condition_3:
do_3() |y = 3
else:
If the iterator fails to re-raise the StopIteration exception (the spec
only says it should, not that it must) I think the return would be ignored
but a subsquent exception would then get converted into a return value. I
think the flag needs reset to avoid this case.
Good catch. I've fixed
[Jim Fulton]
2. I assume it would be a hack to try to use block statements to implement
something like interfaces or classes, because doing so would require
significant local-variable manipulation. I'm guessing that
either implementing interfaces (or implementing a class
Brett C. wrote:
And while the thought is in my head, I think block statements should be viewed
less as a tweaked version of a 'for' loop and more as an extension to
generators that happens to be very handy for resource management (while
allowing iterators to come over and play on the new swing set
Guido van Rossum wrote:
An alternative that solves this would be to give __next__() a second
argument, which is a bool that should be true when the first argument
is an exception that should be raised. What do people think?
I'll add this to the PEP as an alternative for now.
An optional third
[Nick Coghlan]
This is my attempt at a coherent combination of what I like about both
proposals
(as opposed to my assortment of half-baked attempts scattered through the
existing discussion).
PEP 340 has many ideas I like:
- enhanced yield statements and yield expressions
-
[Guido]
An alternative that solves this would be to give __next__() a second
argument, which is a bool that should be true when the first argument
is an exception that should be raised. What do people think?
I'll add this to the PEP as an alternative for now.
[Nick]
An optional third
At 02:50 PM 4/27/05 -0700, Guido van Rossum wrote:
[Guido]
I'm not sure what the relevance of including a stack trace would be,
and why that feature would be necessary to call them coroutines.
[Phillip]
Well, you need that feature in order to retain traceback information when
you're simulating
Guido van Rossum wrote:
- temporarily sidestepping the syntax by proposing 'block' instead of
'with'
- __next__() argument simplified to StopIteration or
ContinueIteration instance
- use continue EXPR to pass a value to the generator
- generator exception handling explained
+1
A minor sticking
[Phillip]
Probably my attempt at a *brief* explanation backfired. No, they're not
continuations or anything nearly that complicated. I'm just simulating
threads using generators that yield a nested generator when they need to do
something that might block waiting for I/O. The pseudothread
A minor sticking point - I don't like that the generator has to re-raise any
``StopIteration`` passed in. Would it be possible to have the semantics be:
If a generator is resumed with ``StopIteration``, the exception is raised
at the resumption point (and stored for later use). When
Guido van Rossum wrote:
A minor sticking point - I don't like that the generator has to
re-raise any ``StopIteration`` passed in. Would it be possible to
have the semantics be:
If a generator is resumed with ``StopIteration``, the exception
is raised at the resumption point (and stored
OK - so what is the point of the sentence::
The generator should re-raise this exception; it should not yield
another value.
when discussing StopIteration?
It forbids returning a value, since that would mean the generator
could refuse a break or return statement, which is a little
On Wed, Apr 27, 2005 at 12:30:22AM -0700, Guido van Rossum wrote:
I've written a PEP about this topic. It's PEP 340: Anonymous Block
Statements (http://python.org/peps/pep-0340.html).
[Note: most of these comments are based on version 1.2 of the PEP]
It seems like what you are proposing is a
Guido van Rossum wrote:
[Guido]
An alternative that solves this would be to give __next__() a second
argument, which is a bool that should be true when the first argument
is an exception that should be raised. What do people think?
I'll add this to the PEP as an alternative for now.
It seems like what you are proposing is a limited form of
coroutines.
Well, I though that's already what generators were -- IMO there isn't
much news there. We're providing a more convenient way to pass a value
back, but that's always been possible (see Fredrik's examples).
Allowing
41 matches
Mail list logo
