[Python-Dev] An issue recently brought up in patch #872326 (generator expression)

[Phillip J. Eby]

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.