Author ncoghlan
Recipients Inyeol.Lee, Jim Fasarakis-Hilliard, arigo, belopolsky, benjamin.peterson, danielsh, emptysquare, erickt, esc24, georg.brandl, glyph, gvanrossum, levkivskyi, ncoghlan, rhettinger, serhiy.storchaka
Date 2017-11-23.06:34:21
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1511418861.58.0.213398074469.issue10544@psf.upfronthosting.co.za>
In-reply-to
Content
"Just fix the issue" is easier said than done for the same reason that comprehensions were implemented the way they are now: lambda expressions still have to work.

That is, we need to maintain the invariant that:

    [x for x in iterable]
    {x for x in iterable}
    (k:v for k, v in iterable)
    (x for x in iterable)

give the same results (respectively) as:

    [(lambda: x)() for x in iterable]
    {(lambda: x)() for x in iterable}
    ((lambda: k)():(lambda: v)() for k, v in iterable)
    ((lambda: x)() for x in iterable)

Once you work through the implications of "We need the loop variable to visible to lexically nested scopes, but invisible in the containing scope", you're going to end up with something that looks enough like a nested function that the easiest to implement and explain option is to have it *be* a nested function.

I'd be fine with a resolution that forbade yield expressions directly inside implicit scopes, though.
History
Date User Action Args
2017-11-23 06:34:21ncoghlansetrecipients: + ncoghlan, gvanrossum, arigo, georg.brandl, rhettinger, belopolsky, benjamin.peterson, erickt, glyph, Inyeol.Lee, serhiy.storchaka, esc24, danielsh, emptysquare, levkivskyi, Jim Fasarakis-Hilliard
2017-11-23 06:34:21ncoghlansetmessageid: <1511418861.58.0.213398074469.issue10544@psf.upfronthosting.co.za>
2017-11-23 06:34:21ncoghlanlinkissue10544 messages
2017-11-23 06:34:21ncoghlancreate