[Python-Dev] An issue recently brought up in patch #872326
(generator expression)
Phillip J. Eby
pje at telecommunity.com
Mon Mar 22 21:13:31 EST 2004
At 01:19 PM 3/23/04 +1200, Greg Ewing wrote:
>Guido:
>
> > A free variable might be a function that itself references globals (or
> > at least nonlocals) that might change.
> >
> > There is also the issue of exceptions:
>
>Oviously there will be semantic differences, but the question is
>whether the consequences of them are serious enough to be worth
>treating the outermost iterator differently from the others.
>
>I'm disturbed by the number of special rules we seem to be needing to
>make up in the name of getting generator expressions to DWIM. First we
>have free variables getting captured, which is unprecedented anywhere
>else; now we have some iterators being treated more equally than
>others.
Maybe I'm confused, but isn't this special treatment of iterators being
done *instead of* free variable capture? My understanding of the original
proposal was that semantically, this:
gen = (x for x in y)
should be translated as if you had written this instead:
def gen(y=y) [lambda x:x()]:
for x in y:
yield x
Now, if y is itself a generator expression, e.g.:
gen = (x for x in (y for y in z))
then a nested translation logically reads reads:
def g1(z=z) [lambda x:x()]:
for y in z:
yield y
def gen(_1=g1):
for x in _1:
yield x
Meanwhile, for multi-generator expressions, it seems the translation from:
gen = (x,y for x in a for y in b)
should be:
def gen(a=a,b=b):
for x in a:
for y in b:
yield x,y
All of these read to me like a straight conversion of the generator
expression to a generator function that is immediately invoked.
More information about the Python-Dev
mailing list