Python becoming less Lisp-like

Jeff Shannon jeffshannon at gmail.com
Wed Mar 16 01:49:11 CET 2005


Martin Franklin wrote:

> Tim Daneliuk wrote:
> 
>>
>> Except that in this case, removal will also complicate code in some
>> cases.  Consider this fragment of Tkinter logic:
>>
>> UI.CmdBtn.menu.add_command(label="MyLabel",
>>                             command=lambda cmd=cmdkey: 
>> CommandMenuSelection(cmd))
>>
> 
> In this case you perhaps should try using a class like so:-
> 
> UI.CmdBtn.menu.add_command(label="MyLabel",
>    command=CommandMenuSelectionCallback(cmdkey))
> 
> Where CommandMenuSelectionCallback is a class like so:
> 
> class CommandMenuSelectionCallback:
>     def __init__(self, key):
>         self.key = key
> 
>     def __call__(self):
>         print self.key
> 

One could equivalently define CommandMenuSelectionCallback as a 
function which creates and returns closures --

def CommandMenuSelectionCallback(key):
     def func():
         CommandMenuSelection(key)
     return func

This should have the same practical value as the callable class; in 
both cases you have a callable taking a single argument, which 
produces a callable taking no arguments.  Whether one prefers that the 
resulting callable object be a class instance or a closure (function) 
seems to me to be largely a matter of taste.

Also, once Python 2.5 is realeased, one should be able to use the 
partial() function (see http://www.python.org/peps/pep-0309.html) to 
accomplish much the same thing in a more general fashion.  ISTM that 
partial() will cover somewhere between 50% and 95% of the current 
(reasonable) uses of lambda -- my guess being that it's towards the 
hight end of that range.

Jeff Shannon




More information about the Python-list mailing list