On 4/29/05, Shane Hathaway [EMAIL PROTECTED] wrote:
I think this concept can be explained clearly. I'd like to try
explaining PEP 340 to someone new to Python but not new to programming.
I'll use the term block iterator to refer to the new type of
iterator. This is according to my limited
On 4/29/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Message: 2
Date: Thu, 28 Apr 2005 21:56:42 -0600
From: Shane Hathaway [EMAIL PROTECTED]
Subject: Re: [Python-Dev] Re: anonymous blocks
To: [EMAIL PROTECTED]
Cc: Ka-Ping Yee [EMAIL PROTECTED], Python Developers List
python-dev
Hello,
Shane Hathaway wrote:
Is it understandable so far?
Definitely yes! I had the structure upside-down; your explanation is
right on target.
Thanks!
--
Luis Bruno
___
Python-Dev mailing list
Python-Dev@python.org
Luis P Caamano wrote:
I've been skipping most of the anonymous block discussion and thus,
I only had a very vague idea of what it was about until I read this
explanation.
Yes, it is understandable -- assuming it's correct :-)
To my surprise, the explanation is now in the PEP. (Thanks,
On Thu, 28 Apr 2005, Shane Hathaway wrote:
[...]
I think this concept can be explained clearly. I'd like to try
explaining PEP 340 to someone new to Python but not new to programming.
[...snip explanation...]
Is it understandable so far?
Yes, excellent. Speaking as somebody who scanned the
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
On Thu, 28 Apr 2005, Greg Ewing wrote:
If such an explanation can't be found, I strongly suspect
that this doesn't correspond to a cohesive enough concept
to be made into a built-in language feature. If you can't
give a short, understandable explanation of it, then it's
probably a bad idea.
On 4/28/05, Steven Bethard [EMAIL PROTECTED] wrote:
however, the iterable object is notified whenever a 'continue',
'break', or 'return' statement is executed inside the block-statement.
This should read:
however, the iterable object is notified whenever a 'continue',
'break' or 'return'
Brett C. wrote:
Guido van Rossum wrote:
Yet another alternative would be for the default behaviour to be to raise
Exceptions, and continue with anything else, and have the third argument be
raise_exc=True and set it to False to pass an exception in without raising it.
You've lost me there. If you
On 4/28/05, Greg Ewing [EMAIL PROTECTED] wrote:
Neil Schemenauer wrote:
The translation of a block-statement could become:
itr = EXPR1
arg = None
while True:
try:
VAR1 = next(itr, arg)
except StopIteration:
Brett C. wrote:
I'm surprisingly close to agreeing with you, actually. I've worked out
that it isn't the looping that I object to, it's the inability to get
out of the loop without exhausting the entire iterator.
'break' isn't' enough for you as laid out by the proposal? The raising of
[Greg Ewing]
I think perhaps I'm not expressing myself very well.
What I'm after is a high-level explanation that actually
tells people something useful, and *doesn't* cop out by
just saying you're not experienced enough to understand
this yet.
If such an explanation can't be found, I
Guido van Rossum wrote:
I don't know. What exactly is the audience supposed to be of this
high-level statement? It would be pretty darn impossible to explain
even the for-statement to people who are new to programming, let alone
generators. And yet explaining the block-statement *must* involve
Guido van Rossum wrote:
I don't know. What exactly is the audience supposed to be of this
high-level statement? It would be pretty darn impossible to explain
even the for-statement to people who are new to programming, let alone
generators.
If the use of block-statements becomes common for certain
Shane Hathaway wrote:
Block statements provide a mechanism for encapsulating patterns of
structure. Code inside the block statement runs under the control of an
object called a block iterator. Simple block iterators execute code
before and after the code inside the block statement. Block
If the use of block-statements becomes common for certain
tasks such as opening files, it seems to me that people are
going to encounter their use around about the same time
they encounter for-statements. We need *something* to
tell these people to enable them to understand the code
they're
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
-
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
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:
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]
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
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
[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
Greg Ewing wrote:
Brett C. wrote:
And before anyone decries the fact that this might confuse a newbie
(which
seems to happen with every advanced feature ever dreamed up), remember
this
will not be meant for a newbie but for someone who has experience in
Python and
iterators at the
[Greg Ewing]
I like the general shape of this, but I have one or two
reservations about the details.
That summarizes the feedback so far pretty well. I think we're on to
something. And I'm not too proud to say that Ruby has led the way here
to some extent (even if Python's implementation would
Brett C. wrote:
It executes the body, calling next() on the argument
name on each time through until the iteration stops.
But that's no good, because (1) it mentions next(),
which should be an implementation detail, and (2)
it talks about iteration, when most of the time
the high-level intent has
Guido van Rossum wrote:
[Greg Ewing]
I like the general shape of this, but I have one or two
reservations about the details.
That summarizes the feedback so far pretty well. I think we're on to
something. And I'm not too proud to say that Ruby has led the way here
to some extent (even if
Guido van Rossum wrote:
[Greg Ewing]
* It seems to me that this same exception-handling mechanism
would be just as useful in a regular for-loop, and that, once
it becomes possible to put 'yield' in a try-statement, people
are going to *expect* it to work in for-loops as well.
(You can already put
Nick Coghlan wrote:
Guido van Rossum wrote:
[snip]
- I think there's a better word than Flow, but I'll keep using it
until we find something better.
How about simply reusing Iteration (ala StopIteration)?
Pass in 'ContinueIteration' for 'continue'
Pass in 'BreakIteration' for
Reinhold Birkenfeld wrote:
Nick Coghlan wrote:
Guido van Rossum wrote:
[snip]
- I think there's a better word than Flow, but I'll keep using it
until we find something better.
How about simply reusing Iteration (ala StopIteration)?
Pass in 'ContinueIteration' for 'continue'
Pass in
Whew! This is a bit long...
On 25 Apr 2005, at 00:57, Guido van Rossum wrote:
After reading a lot of contributions (though perhaps not all -- this
thread seems to bifurcate every time someone has a new idea :-)
I haven't read all the posts around the subject, I'll have to admit.
I've read the
Samuele Pedroni [EMAIL PROTECTED] writes:
Michael Hudson wrote:
The history of iterators and generators could be summarized by
saying that an API was invented, then it turned out that in practice
one way of implementing them -- generators -- was almost universally
useful.
This proposal
Hi, this is my first post here and I've been following this very
interesting discussion as is has developed.
A really short intro about me, I was trained as a computer tech in the
early 80's... ie. learned transistors, gates, logic etc... And so my
focus tends to be from that of a
On Tue, Apr 26, 2005, Guido van Rossum wrote:
Now there's one more twist, which you may or may not like. Presumably
(barring obfuscations or bugs) the handling of BreakFlow and
ContinueFlow by an iterator (or generator) is consistent for all uses
of that particular iterator. For example
Phillip J. Eby wrote:
At 09:12 PM 4/24/05 -0600, Steven Bethard wrote:
I guess it would be helpful to see example where the looping
with-block is useful.
Automatically retry an operation a set number of times before hard failure:
with auto_retry(times=3):
(2) Add a way to say Make this function I'm calling use *my* locals
and globals. This seems to meet all the agreed-upon-as-good use
cases, but there is disagreement over how to sensibly write it. The
calling function is the place that could get surprised, but people
who want thunks seem to
On 4/26/05, Jim Jewett [EMAIL PROTECTED] wrote:
I'm not sure I understand this. The preferred way would be
to just stick the keyword before the call. Using 'collapse', it
would look like:
def foo(b):
c=a
def bar():
a=a1
collapse foo(b1)
print b,
[Jim Jewett]
(2) Add a way to say Make this function I'm calling use *my* locals
and globals. This seems to meet all the agreed-upon-as-good use
cases, but there is disagreement over how to sensibly write it. The
calling function is the place that could get surprised, but people
who
[Paul Moore]
*YUK* I spent a long time staring at this and wondering where did b come
from?
You'd have to come up with a very compelling use case to get me to like this.
I couldn't have said it better.
I said it longer though. :-)
--
--Guido van Rossum (home page:
I don't think this proposal has any chance as long as
it's dynamically scoped.
It mightn't be so bad if it were lexically scoped,
i.e. a special way of defining a function so that
it shares the lexically enclosing scope. This
would be implementable, since the compiler has
all the necessary
[Greg Ewing]
* It seems to me that this same exception-handling mechanism
would be just as useful in a regular for-loop, and that, once
it becomes possible to put 'yield' in a try-statement, people
are going to *expect* it to work in for-loops as well.
[Guido]
(You can already put a yield
Guido van Rossum wrote:
At the same time, having to use it as follows:
for f in with_file(filename):
for line in f:
print process(line)
is really ugly, so we need new syntax, which also helps with keeping
'for' semantically backwards compatible. So let's use
[ Simon Percivall ]:
[ Terry Reedy ]:
with target as value:
would parallel the for-statement header and read smoother to me.
for target as value:
would not need new keyword, but would require close reading to
distinguish
'as' from 'in'.
But it also moves the value to the
Paul Moore wrote:
Hmm, it took me a while to get this, but what you're ssaying is that
if you modify Guido's what I really want solution to use
VAR = next(it, exc)
then this builtin next makes API v2 stuff using __next__ work while
remaining backward compatible with old-style API v1 stuff using
Tim Delaney wrote:
There aren't many builtins that have magic names, and I don't think this
should be one of them - it has obvious uses other than as an
implementation detail.
I think there's some confusion here. As I understood the
suggestion, __next__ would be the Python name of the method
Guido van Rossum wrote:
with VAR = EXPR:
BODY
This would translate to the following code:
it = EXPR
err = None
while True:
try:
if err is None:
VAR = it.next()
else:
VAR = it.next_ex(err)
except
Brett C. wrote:
And before anyone decries the fact that this might confuse a newbie (which
seems to happen with every advanced feature ever dreamed up), remember this
will not be meant for a newbie but for someone who has experience in Python and
iterators at the minimum, and hopefully with
After reading a lot of contributions (though perhaps not all -- this
thread seems to bifurcate every time someone has a new idea :-) I'm
back to liking yield for the PEP 310 use case. I think maybe it was
Doug Landauer's post mentioning Beta, plus scanning some more examples
of using yield in
Guido van Rossum wrote:
[SNIP]
Now let me propose a strawman for the translation of the latter into
existing semantics. Let's take the generic case:
with VAR = EXPR:
BODY
This would translate to the following code:
[SNIP]
it = EXPR
err = None
while True:
At 04:57 PM 4/24/05 -0700, Guido van Rossum wrote:
So a block could return a value to the generator using a return
statement; the generator can catch this by catching ReturnFlow.
(Syntactic sugar could be VAR = yield ... like in Ruby.)
[uncontrolled drooling, followed by much rejoicing]
If this
On Apr 24, 2005, at 11:32 PM, Phillip J. Eby wrote:
At 04:57 PM 4/24/05 -0700, Guido van Rossum wrote:
So a block could return a value to the generator using a return
statement; the generator can catch this by catching ReturnFlow.
(Syntactic sugar could be VAR = yield ... like in Ruby.)
Nick Coghlan wrote:
Interestingly, with this approach, for dummy in my_resource() would still
wrap
the block of code in the entrance/exit code (because my_resource *is* a
generator), but it wouldn't get the try/finally semantics.
An alternative would be to replace the 'yield None' with
On 4/20/05, Samuele Pedroni [EMAIL PROTECTED] wrote:
def do():
print setup
try:
yield None
finally:
print tear down
doesn't quite work (if it did, all you would need is syntactic sugar
for for
dummy in).
PEP325 is about
On Apr 21, 2005, at 6:28 AM, Fredrik Lundh wrote:
Glyph Lefkowitz wrote:
Despite being guilty of propagating this style for years myself, I
have to disagree. Consider the
following network-conversation using Twisted style (which, I might
add, would be generalizable to
other Twisted-like systems
Guido van Rossum wrote:
IMO this is clearer, and even shorter!
But it clutters the namespace with objects you don't need.
Why do people care about cluttering namespaces so much? I thought
thats' what namespaces were for -- to put stuff you want to remember
for a bit. A function's local namespace
Josiah Carlson wrote:
See the previous two discussions on thunks here on python-dev, and
notice how the only problem that seem bettered via blocks/thunks /in
Python/ are those which are of the form...
#setup
try:
block
finally:
#finalization
... and depending on the syntax, properties. I
PS. a side effect of the for-in pattern is that I'm beginning to feel that
Python
might need a nice switch statement based on dictionary lookups, so I can
replace multiple callbacks with a single loop body, without writing too many
if/elif clauses.
That's funny. I keep wondering if match
I guess I should begin by introducing myself: My name is Rüdiger Flaig, I live
in Heidelberg/Germany (yes indeed, there are not only tourists there) and am a
JOAT by profession (Jack Of All Trades). Among other weird things, I am
currently teaching immunology and bioinformatics at the
On Wed, Apr 20, 2005, [EMAIL PROTECTED] wrote:
As students keep on asking me about the differences between languages
and the pros and cons, I think I may claim some familiarity with
other languages too, especially Python's self-declared antithesis,
Ruby.
That seems a little odd to me. To
On Wed, Apr 20, 2005 at 08:18:11AM -0700, Aahz wrote:
antithesis, it would be either C++ or Perl. Ruby is antithetical to some
of Python's core ideology because it borrows from Perl, but Ruby is much
more similar to Python than Perl is.
I'm not that familiar with the Ruby community; might it
Guido van Rossum wrote:
What was your opinion on where as a lambda replacement? i.e.
foo = bar(callback1, callback2) where:
def callback1(x):
print hello,
def callback2(x):
print world!
I don't recall seeing this proposed, but I might have -- I thought of
Fredrik Lundh wrote:
Brian Sabbey wrote:
doFoo(**):
def func1(a, b):
return a + b
def func2(c, d):
return c + d
That is, a suite can be used to define keyword arguments.
umm. isn't that just an incredibly obscure way to write
def func1(a, b):
87 matches
Mail list logo
