pre-PEP: Simple Thunks
Brian Sabbey
sabbey at u.washington.edu
Sat Apr 16 20:21:06 EDT 2005
Leif K-Brooks wrote:
> Brian Sabbey wrote:
>> Thunk statements contain a new keyword, 'do', as in the example below. The
>> body of the thunk is the suite in the 'do' statement; it gets passed to the
>> function appearing next to 'do'. The thunk gets inserted as the first
>> argument to the function, reminiscent of the way 'self' is inserted as the
>> first argument to methods.
>
> It would probably make more sense to pass the thunk as the last argument, not
> as the first. That would make it easier to create functions with optional
> thunks, as in:
>
> def print_nums(start, end, thunk=None):
> for num in xrange(start, end+1):
> if thunk is not None:
> num = thunk(num)
> print num
>
> print_nums(1, 3) # prints 1, 2, 3
>
> do num print_nums(1, 3): # prints 2, 4, 6
> continue num * 2
That seems like a good idea to me.
I suppose it also makes sense to have the thunk last because it appears
after all the other arguments in the function call.
>> Because thunks blend into their environment, a thunk cannot be used after
>> its surrounding 'do' statement has finished
>
> Why? Ordinary functions don't have that restriction:
>
>>>> def foo():
> ... x = 1
> ... def bar():
> ... return x
> ... return bar
> ...
>>>> foo()()
> 1
>
Thunks, as I implemented them, don't create a closure. I believe that
creating a closure will require a performance penalty. Since one use of
thunks is in loops, it seems that their performance may often be
important.
I believe that saving the thunk and calling it a later time is a somewhat
hackish way to use thunks. Explicitly defining a function (perhaps with a
suite-based keyword :) ) seems to me to be a more readable way to go.
But, yes, it is an arbitrary restriction. If it turns out that
performance isn't really affected by creating a closure, or that
performance doesn't matter as much as I think it does, then this
restriction could be lifted.
-Brian
More information about the Python-list
mailing list