[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()
try:
for x in a:
raise Blather
except:
a.next()
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
anonymous:
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.
-Brian
More information about the Python-Dev
mailing list