On Mon, Oct 17, 2011 at 5:52 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
> Nick Coghlan wrote:
>>
>> Yeah, that's a large part of why I now think the given clause needs to
>> be built on the same semantics that we already use internally for
>> implicit out of order evaluation (i.e. decorators, comprehensions and
>> generator expressions), such that it merely exposes the unifying
>> mechanic underlying existing constructs rather than creating a
>> completely new way of doing things.
>
> I'm not sure what you mean by that. If you're talking about
> the implementation, all three of those use rather different
> underlying mechanics. What exactly do you see about these
> that unifies them?

Actually, comprehensions and generator expressions are almost
identical in 3.x (they only differ in the details of the inner loop in
the anonymous function).

For comprehensions, the parallel with the proposed given statement
would be almost exact:

    seq = [x*y for x in range(10) for y in range(5)]

would map to:

    seq = _list_comp given _outermost_iter = range(10):
        _list_comp = []
        for x in _outermost_iter:
            for y in range(5):
                _list_comp.append(x*y)

And similarly for set and dict comprehensions:

    # unique = {x*y for x in range(10) for y in range(5)}
    unique = _set_comp given _outermost_iter = range(10):
        _set_comp = set()
        for x in _outermost_iter:
            for y in range(5):
                _set_comp.add(x*y)

    # map = {(x, y):x*y for x in range(10) for y in range(5)}
    map = _dict_comp given _outermost_iter = range(10):
        _anon = {}
        for x in _outermost_iter:
            for y in range(5):
                _anon[x,y] = x*y

Note that this lays bare some of the quirks of comprehension scoping -
at class scope, the outermost iterator expression can sometimes see
names that the inner iterator expressions miss.

For generator expressions, the parallel isn't quite as strong, since
the compiler is able to avoid the redundant anonymous function
involved in the given clause and just emit an anonymous generator
directly. However, the general principle still holds:

    # gen_iter = (x*y for x in range(10) for y in range(5))
    gen_iter = _genexp() given _outermost_iter = range(10):
        def _genexp():
            for x in _outermost_iter:
                for y in range(5):
                    yield x*y

For decorated functions, the parallel is actually almost as weak as it
is for classes, since so many of the expressions involved (decorator
expressions, default arguments, annotations) get evaluated in order in
the current scope and even a given statement can't reproduce the
actual function statement's behaviour of not being bound at *all* in
the current scope while decorators are being applied, even though the
function already knows what it is going to be called:

>>> def call(f):
...     print(f.__name__)
...     return f()
...
>>> @call
... def func():
...     return func.__name__
...
func
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in call
  File "<stdin>", line 3, in func
NameError: global name 'func' is not defined

So it's really only the machinery underlying comprehensions that is
being exposed by the PEP rather than anything more far reaching.

Exposing the generator expression machinery directly would require the
ability to turn the given clause into a generator (via a top level
yield expression) and then a means to reference that from the header
line, which gets us back into cryptic and unintuitive PEP 403
territory. Better to settle for the named alternative.

Cheers,
Nick.