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
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
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:
> 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
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:
> 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: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
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*
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
> 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
[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
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
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
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
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
> 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
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
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
> 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
[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
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
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]
> > 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
[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 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
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
[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
> 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
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:
[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
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:
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
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
__
> 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 :-)
[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
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
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)
> >
> 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
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
> 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:
>
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
> 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
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
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
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
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
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
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
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
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
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
-
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
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
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
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
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
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
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
60 matches
Mail list logo
