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

Steve Holden steve at holdenweb.com
Tue Dec 6 11:59:04 CET 2005

bonono at gmail.com wrote:
> Paul Rubin wrote:
>>bonono at gmail.com writes:
>>>I think there is, for python. Not that I agree with it. The language
>>>doesn't prevent you from using the short one-liner style but the idioms
>>>prefer the line by line(and one single op/action per line) style.
>>Are you serious?!!  You're saying idiomatic Python prefers
>>     temp1 = a + b
>>     temp2 = c * d
>>     temp3 = temp1 + temp2
>>     x = temp3 + e
>>     x = a + b + (c * d) + e
>>I don't think you look at the same Python code I do ;-).
> Not for this particular example, but that is the impression I get, I
> said the "form/style". Especially when we are talking about
> reduce/map/filter vs explicit for loop.
There's a balance to be struck. Some of it will depend on personal 
taste, and no matter how prescriptive "the rules" may be there is and 
always should be room for some degree of personal style.

The point I was trying to make (about namespace pollution, originally) 
is that namespaces exist precisely so we can bind names to values. If a 
program is properly composed then most names aren't that long-lived 
anyway because they go out of scope at the end of the function call 
during which their bindings are made.

One perhaps needs to be a little more careful with instance variables, 
but again most *temporaries* are simply local to the method in which 
they're called, they don't exist for the lifetime of the instance.

One shouldn't obsess about every little detail - Python is ultimately 
for solving problems. I see plenty of code I wouldn't necessarily write 
myself on this list, but as long as it solves the poster's problem and 
doesn't contain any egregious errors I'm happy to let it by.

For the record, this includes uses of reduce, map and filter: I don't 
naturally favour a functional style myself, but I can live quite happily 
alongside those who do. The same will be true of the ternary x if y else 
z construct when it arrives.

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

More information about the Python-list mailing list