PEP 312 - Making lambdas implicit worries me, surely it's just the name 'lambda' that is bad...

[Alexander Schmolck]

Erik Max Francis <max at alcyone.com> writes:

> Indeed.  I don't see what the tangible benefit is, except by making a
> certain style of lambdas harder to read.  One might object to the use of
> lambdas on general grounds, but certainly when you see the keyword
> `lambda' you know what you're in for.  PEP 312 attempts to blur that
> distinction, for no other reason than to save keystrokes and make code
> look more impenetrable.  I don't see the benefit.

You overlook the fact "that saving keystrokes" (and space) can make a
qualitative change to a language. Certain styles of doing things only become
viable if they don't involve too many keystrokes. For example, thanks to its
lightweight lambda-syntax, smalltalk has a very simple syntax and powerful
methods. If ``[x]`` became ``lambda : x``, it would be completely unusable.

Compare:

Smalltalk:                                  Python:
                                            
... someBool ifTrue: [1] ifFalse: [2]       apparently needs a ternary operator...

                                            
... someContainer at: 3 ifAbsent: [0]       try:
                                                ... someContainer[3] ...
                                            except IndexError, KeyError:
                                                ... 0 ...

                                            # easy
... someDict at: 3 ifAbsent: [0]            ... someDict.get(3, 0)

                                            # oops
... someDict at: 3 ifAbsent: [val compute]  if someDict.has_key(3):
                                               ...
                                            else:
                                               ... val.compute() ...

alex