[Python-Dev] code blocks using 'for' loops and generators

Brian Sabbey sabbey at u.washington.edu
Tue Mar 15 00:41:21 CET 2005

> be guaranteed to run under all conditions, I think it
> would be useful if it could be arranged so that
>  for x in somegenerator():
>    ...
>    raise Blather
>    ...
> would caused any finallies that the generator was suspended
> inside to be executed. Then the semantics would be the
> same as if the for-loop-over-generator were implemented by
> passing a thunk to a function that calls it repeatedly.

One difficulty is that one can never know if the user intends to still use 
the generator, like so:

a = somegenerator()
 	for x in a:
 		raise Blather

I think they only way you can really be sure .next() will not be called 
again is if the generator is no longer referenced.  Someone submitted a 
patch once to execute "finallies" when the generator is __del__eted, but 
it was rejected for various reasons.

In my original post in this thread I tried to provide a mechanism such as 
you describe by providing __call__ as an alternative to 'next', but now I 
am convinced that it is better to introduce a new syntax instead of 
re-using generators.

Incidentally, passing the thunk "behind the scenes" as the first argument 
(as mentioned previously) allows one to avoid using lambda to do things 
such as sort (I hear lambdas are on the way out), while remaining 

with x, y from a.sort():
 	value cmp(x.k1, y.k1) or (x.k2, y.k2)

(or whatever the preferred syntax is) instead of:

a.sort(lambda x,y : cmp(x.k1, y.k1) or (x.k2, y.k2))

Not that I find either form better than the other, but I do find both 
better than have to define a named function.

I am going to see if I can make a PEP for this.


More information about the Python-Dev mailing list