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 with resource
>management.
>
>I initially decided it should not call iter() so as to emphasize that
>this isn't supposed to be used for looping over sequences -- EXPR1 is
>really expected to be a resource management generator (or iterator).
Which is why I vote for not calling iter(), and further, that blocks not
use the iteration protocol, but rather use a new "block template"
protocol. And finally, that a decorator be used to convert a generator
function to a "template function" (i.e., a function that returns a block
template).
I think it's less confusing to have two completely distinct concepts, than
to have two things that are very similar, yet different in a blurry kind of
way. If you want to use a block on an iterator, you can always explicitly
do something like this:
@blocktemplate
def iterate(iterable):
for value in iterable:
yield value
block iterate([1,2,3]) as x:
print x
> > I wonder if generators that contain a yield-expression should
> > properly be called coroutines. Practically, I suspect it would just
> > cause confusion.
>
>I have to admit that I haven't looked carefully for use cases for
>this!
Anything that wants to do co-operative multitasking, basically.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4