Python becoming less Lisp-like

[Martin Franklin]

Tim Daneliuk wrote:
> In-Reply-To: <slrnd3da07.v6h.nick at irishsea.home.craig-wood.com>
> X-Enigmail-Version: 0.90.0.0
> X-Enigmail-Supports: pgp-inline, pgp-mime
> Content-Type: text/plain; charset=us-ascii; format=flowed
> Content-Transfer-Encoding: 7bit
> 
> Nick Craig-Wood wrote:
> 
> 
>>Torsten Bronger <bronger at physik.rwth-aachen.de> wrote:
>>
>>
>>>The current snapshot is a transitional Python and thus
>>>with some double features.  The numerical types and two kinds of
>>>classes are examples.  I'm very surprised about this, because Python
>>>is a production language, but I'm happy, too.
>>
>>
>>As long as python 2.x -> 3.x/3000 isn't like perl 5.x -> perl 6.x I'll
>>be perfectly happy too.
>>
>>"Less is more" is a much better philosophy for a language and having
>>the courage to take things out differentiates python from the crowd.
>>
>>Of course we users will complain about removals, but we'll knuckle
>>down and take our medicine eventually ;-)
>>
> 
> 
> 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

> Would it not be the case that, without lambda, we will need to pollute
> the name space with a bunch of specialized little functions for each
> and every construct like this?
>