pre-PEP: Simple Thunks

[Ron_Adam]

On Sun, 17 Apr 2005 15:02:12 -0700, Brian Sabbey
<sabbey at u.washington.edu> wrote:

Brian Sabbey wrote:

> I'm kicking myself for the first example I gave in my original post in 
> this thread because, looking at it again, I see now that it really gives 
> the wrong impression about what I want thunks to be in python.  The 
> 'thunkit' function above shouldn't be in the same namespace as the thunk. 
> It is supposed to be a re-usable function, for example, to acquire and 
> release a resource.  On the other hand, the 'foo' function is supposed to 
> be in the namespace of the surrounding code; it's not re-usable.  So your 
> example above is pretty much the opposite of what I was trying to get 
> across.

This would explain why I'm having trouble seeing it then.


> def pickled_file(thunk, name):
>  	f = open(name, 'r')
>  	l = pickle.load(f)
>  	f.close()
>  	thunk(l)
>  	f = open(name, 'w')
>  	pickle.dump(l, f)
>  	f.close()
>
> Now I can re-use pickled_file whenever I have to modify a pickled file:
>
> do data in pickled_file('pickled.txt'):
>  	data.append('more data')
>  	data.append('even more data')
>
> In my opinion, that is easier and faster to write, more readable, and less 
> bug-prone than any non-thunk alternative.
>

The above looks like it's missing something to me. How does 'data'
interact with 'thunk(l)'?  What parts are in who's local space?  
	

This might be the non-thunk version of the above. 

def pickled_file(thunk, name):
 	f = open(name, 'r')
 	l = pickle.load(f)
 	f.close()
 	thunk(l)
 	f = open(name, 'w')
 	pickle.dump(l, f)
 	f.close()

def data_append(L):
	L.append('more data')
	L.append('still more data')

pickled_file(data_append, name)

I don't think I would do it this way.  I would put the data
list in a class and add a method to it to update the pickle file. Then
call that from any methods that update the data list.


>> def with_file:				# no argument list, local group.
>> 	f = open(filename)
>> 	t = callback(f)
>> 	f.close
>>
>> def my_read(f):
>> 	return f.read()
>>
>> callback = my_read
>> filename = 'filename'
>> do with_file
>
> This wouldn't work since with_file wouldn't be re-usable.  It also doesn't 
> get rid of the awkwardness of defining a callback.

As long as the name with_file isn't rebound to something else it could
be used as often as needed.  I admit there are better ways to do it
though.


Cheers,
Ron