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
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,
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
http://mail.python.org/mailman/li
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
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 lim
Greg Ewing <[EMAIL PROTECTED]> wrote:
> That actually looks pretty reasonable.
>
> Hmmm. "Patterns of structure." Maybe we could call it a
> "struct" statement.
>
> struct opening(foo) as f:
>...
>
> Then we could confuse both C *and* Ruby programmers at
> the same time! :-)
And Py
> 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
> the
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 iterat
Steven Bethard wrote:
"""
A block-statement is much like a for-loop, and is also used to iterate
over the elements of an iterable object.
No, no, no. Similarity to a for-loop is the *last* thing
we want to emphasise, because the intended use is very
different from the intended use of a for-loop. Th
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
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* invo
[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
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
StopIterat
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 Stop
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 yo
On 4/28/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
> 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-st
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' st
Greg Ewing wrote:
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
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 ide
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
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
[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
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
> 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
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
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
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
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
> > [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 alre
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 informat
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_part_2
with block
Nick Coghlan wrote:
Accordingly, I would like to suggest that 'with' revert to something
resembling the PEP 310 definition:
resource = EXPR
if hasattr(resource, "__enter__"):
VAR = resource.__enter__()
else:
VAR = None
try:
try:
BODY
except:
[Guido]
> OK, now you *must* look at the Boo solution.
> http://boo.codehaus.org/Syntactic+Macros
That is an interesting solution, requiring macro writers to actually
write an AST modifier seems pretty reasonable to me. Whether we want
macros or not...
- Josiah
__
[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: http://www.python.
[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 p
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")
>
>> (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 thu
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):
do_something_that_might_fail()
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
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 troublesho
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.
>>
>> T
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 seems a bit like an effort to make generators good
> (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 s
Michael Hudson:
> This proposal seems a bit like an effort to make generators good at
> doing something that they aren't really intended -- or dare I say
> suited? -- for.
I think it is more an effort to use the right keyword, which has
unfortunately already been claimed by generators (and li
Michael Hudson wrote:
This is a non-starter, I hope. I really meant what I said in PEP 310
about loops being loops.
The more I play with this, the more I want the 'with' construct to NOT be a loop
construct.
The main reason is that it would be really nice to be able to write and use a
multipar
On 26 Apr 2005, at 15:13, Michael Hudson wrote:
So, here's a counterproposal!
And a correction!
with expr as var:
... code ...
is roughly:
def _(var):
... code ...
try:
expr(_)
except Return, e:
return e.value
Cheers,
mwh
___
Python-Dev mai
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 on
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 'BreakItera
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 'BreakIterati
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 a
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 'break'
Pass in 'AbortIteration' f
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 (e
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
[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
On Mon, 25 Apr 2005, Brett C. wrote:
> It executes the body, calling next() on the argument name on each
> time through until the iteration stops.
There's a little more to it than that. But on the whole I do support
the goal of finding a simple, short description of what this construct
is intende
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
>> iterator
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 generat
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 StopIter
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
corr
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
1 - 100 of 138 matches
Mail list logo
