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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4