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
- use
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 i
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 using
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 StopIteratio
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 ContinueIt
> "Greg" == Greg Ewing <[EMAIL PROTECTED]> writes:
Greg> I didn't claim that people would feel compelled to eliminate
Greg> all uses of lambda; only that, in those cases where they
Greg> *do* feel so compelled, they might not if lambda weren't
Greg> such a long word.
Sure, I u
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 ContinueIt
Greg Ewing wrote:
Nick Coghlan wrote:
def template():
# pre_part_1
yield None
# post_part_1
yield None
# pre_part_2
yield None
# post_part_2
yield None
# pre_part_3
yield None
# post_part_3
def user():
block = template()
with block:
# do_part_1
with block:
# do_p
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
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
- enhanced continue and break
-
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 or a return with
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 retur
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 insid
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
At 04:37 AM 4/26/05 -0700, Guido van Rossum wrote:
*Fourth*, and this is what makes Greg and me uncomfortable at the same
time as making Phillip and other event-handling folks drool: from the
previous three points it follows that an iterator may *intercept* any
or all of ReturnFlow, BreakFlow and C
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 awkwa
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 a
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 s
> 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
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:
>
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:
c:\develope\backup\ba
> 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
http://mail.python.org/mai
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)
> >
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 StopIterati
[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. Althoug
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 state
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 argum
[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 option
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 simul
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 po
[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 pseudothr
> 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). W
Tim Delaney wrote:
Also, within a for-loop or block-statement, we could have ``raise
`` be equivalent to::
arg =
continue
For this to work, builtin next() would need to be a bit smarter ...
specifically, for an old-style iterator, any non-Iteration exception would
need to be re-raised ther
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 fo
> 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
Nick Coghlan wrote:
> 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
At 03:58 PM 4/27/05 -0700, Guido van Rossum wrote:
OK, I sort of get it, at a very high-level, although I still feel this
is wildly out of my league.
I guess I should try it first. ;-)
It's not unlike David Mertz' articles on implementing coroutines and
multitasking using generators, except that I
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
[Phillip]
> It's not unlike David Mertz' articles on implementing coroutines and
> multitasking using generators, except that I'm adding more "debugging
> sugar", if you will, by making the tracebacks look normal. It's just that
> the *how* requires me to pass the traceback into the generator. At
> 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 'contin
On Wed, Apr 27, 2005 at 03:58:14PM -0700, Guido van Rossum wrote:
> Time to update the PEP; I'm pretty much settled on these semantics
> now...
[I'm trying to do a bit of Guido channeling here. I fear I may not
be entirely successful.]
The the __error__ method seems to simplify things a lot. Th
Guido van Rossum wrote:
[SNIP]
>>It's interesting that there is such similarity between 'for' and
>>'block'. Why is it that block does not call iter() on EXPR1? I
>>guess that fact that 'break' and 'return' work differently is a more
>>significant difference.
>
>
> Well, perhaps block *should*
At 05:19 PM 4/27/05 -0700, Guido van Rossum wrote:
[Phillip]
> This also has the benefit of making the delineation between template blocks
> and for loops more concrete. For example, this:
>
> block open("filename") as f:
> ...
>
> could be an immediate TypeError (due to the lack of
Neil Schemenauer wrote:
> On Wed, Apr 27, 2005 at 03:58:14PM -0700, Guido van Rossum wrote:
>
>>Time to update the PEP; I'm pretty much settled on these semantics
>>now...
>
>
> [I'm trying to do a bit of Guido channeling here. I fear I may not
> be entirely successful.]
>
> The the __error__
At 05:43 PM 4/27/05 -0700, Guido van Rossum wrote:
Well, perhaps block *should* call iter()? I'd like to hear votes about
this. In most cases that would make a block-statement entirely
equivalent to a for-loop, the exception being only when there's an
exception or when breaking out of an iterator w
Neil Schemenauer wrote:
> For generators, calling __error__ with a StopIteration instance
> would execute any 'finally' block. Any other argument to __error__
> would get re-raised by the generator instance.
This is only one case right? Any exception (including StopIteration)
passed to a generat
Phillip J. Eby wrote:
> At 05:19 PM 4/27/05 -0700, Guido van Rossum wrote:
> >I'm not convinced of that, especially since all *generators* will
> >automatically be usable as templates, whether or not they were
> >intended as such. And why *shouldn't* you be allowed to use a block
> >for looping, if
Neil Schemenauer wrote:
The translation of a block-statement could become:
itr = EXPR1
arg = None
while True:
try:
VAR1 = next(itr, arg)
except StopIteration:
break
try:
arg = None
Guido van Rossum wrote:
And surely you exaggerate. How about this then:
The with-statement is similar to the for-loop. Until you've
learned about the differences in detail, the only time you should
write a with-statement is when the documentation for the function
you are calling s
60 matches
Mail list logo
