[Python-Dev] Re: anonymous blocks
Phillip J. Eby
pje at telecommunity.com
Thu Apr 28 03:00:01 CEST 2005
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 a __resume__) instead
> > of biting you later on in the block when you try to do something with f, or
> > because the block is repeating for each line of the file, etc.
>
>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 you like the exit behavior (guaranteeing that the
>iterator is exhausted when you leave the block in any way)?
It doesn't guarantee that, does it? (Re-reads PEP.) Aha, for *generators*
it does, because it says passing StopIteration in, stops execution of the
generator. But it doesn't say anything about whether iterators in general
are allowed to be resumed afterward, just that they should not yield a
value in response to the __next__, IIUC. As currently written, it sounds
like existing non-generator iterators would not be forced to an exhausted
state.
As for the generator-vs-template distinction, I'd almost say that argues in
favor of requiring some small extra distinction to make a generator
template-safe, rather than in favor of making all iterators
template-promiscuous, as it were. Perhaps a '@block_template' decorator on
the generator? This would have the advantage of documenting the fact that
the generator was written with that purpose in mind.
It seems to me that using a template block to loop over a normal iterator
is a TOOWTDI violation, but perhaps you're seeing something deeper here...?
More information about the Python-Dev
mailing list