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

[Alexander Schmolck]

Andrew Koenig <ark at research.att.com> writes:

> Alex> (Hint: in case the point of how mere "differences in keystrokes"
> Alex> can widely affect design choices in a language and its libraries
> Alex> was lost on you; do you really think anyone would dream of
> Alex> introducing a ternary operator if you could just do
> 
> Alex>  def when(cond, a,b):
> Alex>      if cond: return a()
> Alex>      else: return  b()
> 
> Alex>  res = when(cond, :b, :c)
> 
> Alex> instead of
> 
> 
> Alex>  res = when(cond, lambda : b, lambda :c)
> 
> Alex> ?)
> 
> Yes, definitely.
> 
> What's wrong with   when(cond, :b, :c)   is that it's too easy to forget
> one of the colons, in which case the error goes undiagnosed until the
> corresponding branch is actually executed.

[...]
 
> For that reason, although I wouldn't mind having a more compact way of
> writing lambda-expressions, I don't think that the colon syntax is
> the best way to do it.

Fair enough, my main point simply was that apparently small differences in
verbosity of constructs do sometimes matter *a lot*, to the extent that not
only library interfaces but even language design decisions can be affected by
it.

Whether or not :x is a good way to write lambda: x, my bet would still be that
*if* a similar lighweight lambda idiom had already existed, the chances of a
ternary making it into the language would be nil.

alex