Tim Daneliuk wrote:
In-Reply-To: <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]> 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?
--
http://mail.python.org/mailman/listinfo/python-list
