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

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