PEP 312 - Making lambdas implicit worries me, surely it's just the name 'lambda' that is bad...
a.schmolck at gmx.net
Mon Mar 3 19:21:14 CET 2003
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
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.
More information about the Python-list