On Tue, 20 Oct 2009 09:33:48 am Michael Foord wrote:
2009/10/19 Oleg Broytman <phd@phd.pp.ru>
On Mon, Oct 19, 2009 at 10:28:58PM +0800, starwing wrote:
Oleg Broytman ??????:
Single-line lambdas are good enough, and if you need more - just create a named function.
BUT, why we need a name? just to process something or make decide, sometimes code itself is enough.
A multiline function is certainly not a simple piece of code; it requires documentation - docstring, comments - and the name is a part of the documentation.
Having used languages that allow multiline anonymous functions (C#, Javascript) I have to say that they *can* improve the readability of code.
Given the difficulty in testing such anonymous functions, what do they do to the correctness of programs?
Being forced to define functions ahead of where they belong in the logical flow of the program is not a feature of Python but a restriction.
I don't see that this restriction is worth the hours and hours people have spent on it. If I have code like this: function(1, None, True, { # define an anonymous dict 'a': set([1, 2, 4, 8, ...], 'b': set([2, 4, 6, 9, 12, 16, 20, ...], 'c': set([1234, 1342, 1432, ...], ... 'z': set([12, 99, 151, 153, 745, ...]) }, flag, count=4, parrot='red') with a complicated data argument, then I can write it as an anonymous variable, but it actually hurts readability to do so. There's no problem with creating an anonymous dict of any complexity I like, but for readability and correctness I'm better off pulling it out of the function call and giving it a name: d = { 'a': set([1, 2, 4, 16, 128, ...], 'b': set([2, 4, 6, 9, 12, 16, 20, ...], 'c': set([1234, 1342, 1432, ...], ... 'z': set([12, 99, 151, 153, 745, ...]) } # print d function(1, None, True, d, flag, count=4, parrot='red') In fact, if it's that complicated, I'm better off creating a function to generate it, so I can test it: function(1, None, True, d_factory(), flag, count=4, parrot='red') My point is that when it comes to data, we have anonymous data that is easy and straightforward to define, and yet we *still* prefer to give data names and define it ahead of where we use it. So why is code different? Why does defining code ahead of where you use it such a bad thing that the lambda restriction generates so much attention? -- Steven D'Aprano