[Python-Dev] Anonymous blocks: Thunks or iterators?

Jim Jewett jimjjewett at gmail.com
Fri Apr 29 20:23:05 CEST 2005


Guido van Rossum:

> -- but it's more efficient, since calling yield doesn't create a frame. 

Neither should a thunk.

> The other problem with thunks is that once we think of them as the
> anonymous functions they are, we're pretty much forced to say that a
> return statement in a thunk returns from the thunk rather than from
> the containing function. 

Why should a thunk be a function?  We already have first class
functions.  What we're missing is a way to pass around a suite.

def foo(a):
    if a > 4:
        b = a
        c = process(a)  # thunk line 1
        print a         # thunk line 2
        return          # thunk line 3
    else:
        a.something()

We don't have a good way to package up "c = process(a); print a; return"

The return should exit the whole function, not just (part of) the if clause.

Greg:
>> I'd like to reconsider a thunk implementation. It
>> would be a lot simpler, doing just what is required
>> without any jiggery pokery with exceptions and
>> break/continue/return statements. It would be easy
>> to explain what it does and why it's useful.

> I don't know. In order to obtain the required local variable sharing
> between the thunk and the  containing function I believe that every
> local variable used or set in the thunk would have to become a 'cell'
> (our mechanism for sharing variables between nested scopes). 

Cells only work if you have a complete set of names at compile-time.
Your own resource-example added "item" to the namespace inside
a block.  If you don't know which blocks could be used with a pattern,
cells are out.

That said, the compiler code is already two-pass.  Once to find names,
and another time to resolve them.  This just means that for thunks
(and functions that call them) the adjustment will be to LOAD_NAME
instead of getting a LOAD_FAST index.

-jJ


More information about the Python-Dev mailing list