what's wrong with "lambda x : print x/60,x%60"

[Steve Holden]

rurpy at yahoo.com wrote:
> "Gary Herron" <gherron at islandtraining.com> wrote in message
> news:mailman.1600.1133766805.18701.python-list at python.org...
> 
>>--snip--
>>So just use a def.  It is constantly pointed out on
>>this list that the lambda provides no extra expressive power, it is
>>merely a shortcut
> 
> 
> No, it is not merely a shortcut.  It often allows one to avoid
> polluting
> the namespace with a completely superfluous function name, thus
> reducing code smell.  It can also avoid a multi-line function defintion
> which often pushes other relevant code off the current page and
> out of view, and thus lambda can increase program readability.
> 
I'm getting a little tired of "namespace pollution" being trotted out as 
a reason to use lambda. Defining a function, and giving it a name, isn't 
"polluting the namespace", any more than assigning sub-expressions to 
temporary variables is polluting the namespace. Why use temporary 
variables when all you have to do is make your expressions three lines 
long to avoid "polluting the namespace"?

For future reference, "polluting the namespace" is doing something 
stupid like

     from cgi import *

which will essentially dump a huge number of unknown names, some of 
which you may have decided to use for yourself already, into the local 
namespace.

Even without shouting "Namespaces are a honking good idea, let's do more 
of those", I should just like to make a small plea for everyone to 
remember that namespaces are there specifically to allow us to name things!
> 
>> and, as you just found out, a rather restrictive one
>>at that.
> 
> 
> In part because Python's designers failed to make "print" a function
> or provide an if-then-else expression.
> 
But they did provide file.write(), which while not perhaps as convenient 
as print is quite easy to use. Though not as easy, I'll admit, as 
spouting on comp.lang.py ;-). But I just *know* that there'll be as many 
complaints about the absence of the print statement from Python 3 as 
there are about its presence (as a statement rather than a function) in 
Python 2.

As for the if-then-else expression, I suspect I'll use the ternary 
operator very infrequently, as I don't myself see many readability 
advantages to it. Its major value to me will be cutting down the cruft 
we see in this newsgroup.

Paul Rubin wrote:
 > Sybren Stuvel <sybrenUSE at YOURthirdtower.com.imagination> writes:
 >
 >>>No, it is not merely a shortcut.  It often allows one to avoid
 >>>polluting the namespace with a completely superfluous function name,
 >>>thus reducing code smell.
 >>
 >>Which can also be done by using inner functions.
 >
 >
 > Inner functions with no names?
 >
Well, you could give them all the same name if you define them just 
before they're used :-)

 >
 >>>It can also avoid a multi-line function defintion which often pushes
 >>>other relevant code off the current page and out of view, and thus
 >>>lambda can increase program readability.
 >>
 >>def somefunc(x): return x*5
 >>How is that a multi-line function definition?
 >
 >
 >     def mult_by_five():
 >        def somefunc(x): return x*5
 >        return somefunc
 >
 > is multi-line, as opposed to:
 >
 >     def mult_by_five(): return lambda x: x*5

Again I'm a little tired of suggestions that reducing things to one-line 
form necessarily improves readbility. If your functions are so long that 
  it's important to add as few lines as possible to them you should fix 
this by refactoring your code to avoid over-long functions.

regards
  Steve
-- 
Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC                     www.holdenweb.com
PyCon TX 2006                  www.python.org/pycon/