Lambda going out of fashion

[Stephen Thorne]

Hi guys,

I'm a little worried about the expected disappearance of lambda in
python3000. I've had my brain badly broken by functional programming
in the past, and I would hate to see things suddenly become harder
than they need to be.

An example of what I mean is a quick script I wrote for doing certain
actions based on a regexp, which I will simlify in this instance to
make the pertanant points more relevent.

{
'one': lambda x:x.blat(),
'two': lambda x:x.blah(),
}.get(someValue , lambda x:0)(someOtherV alue)

The alternatives to this, reletively simple pattern, which is a rough
parallel to the 'switch' statement in C, involve creating named
functions, and remove the code from the context it is to be called
from (my major gripe).

So, the questions I am asking are:
Is this okay with everyone?
Does anyone else feel that lambda is useful in this kind of context?
Are there alternatives I have not considered?

merrily-yr's
Stephen.

[Skip Montanaro]

Keith> My personal gripe is this. I think the core language, as of 2.3
Keith> or 2.4 is very good, has more features than most people will ever
Keith> use, and they (Guido, et al.) can stop tinkering with it now and
Keith> concentrate more on the standard libraries.

What keeps you from being part of the "et al"? This is open source, after
all. Note that there's more to be done than simply writing code.
Documentation always needs attention. Bug reports and patches always need
to be verified and vetted. Even mundane stuff like managing mailing lists
detracts from the time the most experienced people could spend writing code
you might not be able to do. There's lots to do. Start here:

http://www.python.org/dev/

Go anywhere. <wink>

Skip

[Skip Montanaro]

Craig> IMO the reference behaviour of functions in the C API could be
Craig> clearer. One often has to simply know, or refer to the docs, to
Craig> tell whether a particular call steals a reference or is reference
Craig> neutral. Take, for example, PyDict_SetItemS tring vs
Craig> PyMapping_SetIt emString . Is it obvious that one of those steals
Craig> a reference, and one is reference neutral? Is there any obvious
Craig> rationale behind this?

Sure. PyDict_SetItemS tring was first written very early on in Python's
development (actually, it was originally called something
namespace-ly-dangerous like dict_setstring) . PyMapping_SetIt emString (part
of the abstract objects api) was written later with an emphasis on the
consistency of behavior you desire. You're generally going to be better off
sticking with the abstract objects api. For obvious reasons of backward
compatibility, the concrete apis (PyDict_*, PyList_*, etc) must be retained.

Skip

[tanghaibao]

I have this book called TEXT PROCESSING IN PYTHON by David Mertz on
hand, it is a good book and in the first chapter it is really a show
room for higher-order functions which I may now cite to remind you of
the FLEXIBILITY of this keyword.
''' combinatorial.p y

from operator import mul, add, truth
apply_each = lambda funs, args = []: map(apply, fns, [args]*len(fns))
bools = lambda lst: mpa(truth, lst)
bool_each = lambda fns, args = []: bools(apply_eac h(fns, args))
conjoin = lambda fns, args = []: reduce(mul, bool_each(fns, args))
all = lambda fns: lambda arg, fns = fns: conjoin(fns, (arg,))
both = lambda f,g: all(f(f,g))
all3 = lambda f,g,h: all((f,g,h))
and_ = lambda f,g: lambda x, f=f, g=g: f(x) and g(x)
disjoin = lambda fns, args = []: reduce(add, bool_each(fns, args))
some = lambda fns: lambda arg, fns = fns: disjoin(fns, (arg,))
either = lambda f,g: some((f,g))
anyof3 = lambda f,g,h: some((f,g,h))
compose = lambda f,g: lambda x, f=f, g=g: f(g(x))
compose3 = lambda f,g,h: lambda x, f=f, g=g, h=j: f(g(h(x)))
ident = lambda x:x
'''
And some other lambda function usage is when they are treated like
objects, they can also fit in generators... THIS IS ART. Well, some may
argue that it is hard for people to maintain these codes, put the
problem to Haskell people and see how they respond(at least you don't
need to scroll up and down...) Oh! So when did python adopt simplicity
rather than verbosity?

Q: It simply doesn't FIT.
A: OK, OK, get all these map, filter stuff away, and go python, go and
get mixed with them.

[Steven Bethard]

ta********@gmai l.com wrote:

I have this book called TEXT PROCESSING IN PYTHON by David Mertz on
hand, it is a good book and in the first chapter it is really a show
room for higher-order functions which I may now cite to remind you of
the FLEXIBILITY of this keyword.
I'm not exactly sure what you mean by "flexibilit y"; all of these
examples can be written without lambdas:
apply_each = lambda funs, args = []: map(apply, fns, [args]*len(fns))
def apply_each(fns, args=[]):
return [fn(*args) for fn in fns]
bools = lambda lst: mpa(truth, lst)
def bools(lst):
return [bool(x) for x in lst]
bool_each = lambda fns, args = []: bools(apply_eac h(fns, args))
def bool_each(fns, args=[]):
return bools(apply_eac h(fns, args))
conjoin = lambda fns, args = []: reduce(mul, bool_each(fns, args))
def conjoin(fns, args=[]):
reduce(mul, bool_each(fns, args))
all = lambda fns: lambda arg, fns = fns: conjoin(fns, (arg,))
def all(fns):
def _(arg):
return conjoin(fns, (arg,))
return _
both = lambda f,g: all(f(f,g))
def both(f, g):
return all(f(f,g))
all3 = lambda f,g,h: all((f,g,h))
def all3(f, g, h):
return all((f,g,h))
and_ = lambda f,g: lambda x, f=f, g=g: f(x) and g(x)
def and_(f, g):
def _(x):
return f(x) and g(x)
return _
disjoin = lambda fns, args = []: reduce(add, bool_each(fns, args))
def disjoin(fns, args=[]):
return reduce(add, bool_each(fns, args))
some = lambda fns: lambda arg, fns = fns: disjoin(fns, (arg,))
def some(fns):
def _(arg):
return disjoin(fns, (arg,))
return _
either = lambda f,g: some((f,g))
def either(f, g):
return some((f,g))
anyof3 = lambda f,g,h: some((f,g,h))
def anyof3(f, g, h):
return some((f,g,h))
compose = lambda f,g: lambda x, f=f, g=g: f(g(x))
def compose(f, g):
def _(x):
return f(g(x))
return _
compose3 = lambda f,g,h: lambda x, f=f, g=g, h=j: f(g(h(x)))
def compose3(f, g, h):
def _(x):
return f(g(h(x)))
return _
ident = lambda x:x

def ident(x):
return x
Steve

[tanghaibao]

Thanks. :-) Two remarks.
o One-liner fits the eyes & brains of a portion of people.
o Why don't you just say all python can be written in equivalent java,
can I assert that Guido doesn't want to get mixed with those
mainstream>?

[Fredrik Lundh]

ta********@gmai l.com wrote:

o Why don't you just say all python can be written in equivalent java,

your argumentation skills are awesome.

</F>

[Fredrik Lundh]

"jfj" wrote:

Personally I'm not a fan of functional programming but lambda *is* useful when I want to say for
example:

f (callback=lambd a x, y: foo (y,x))

I don't believe it will ever disappear.

agreed. there's no reason to spend this christmas rewriting your programs, folks.
I'm sure you all have better things to do ;-)

cheers /F

[Kent Johnson]

Robin Becker wrote:

Alex Martelli wrote:
.....

By the way, if that's very important to you, you might enjoy Mozart
(http://www.mozart-oz.org/)

.....very interesting, but it wants to make me install emacs. :(

Apparently you can also use oz with a compiler and runtime engine...see
http://www.mozart-oz.org/documentati...tut/index.html

Kent

[Alex Martelli]

<ta********@gma il.com> wrote:

Thanks. :-) Two remarks.
o One-liner fits the eyes & brains of a portion of people.

True! So, personally, I'd rather code, e.g.,

def bools(lst): return map(bool, lst)

rather than breal this one-liner into two lines at the colon, as per
standard Python style. However, uniformity has its advantages, too; I'm
ready for the one-liner style to be outlawed in Python 3.0, purely in
the advantage of uniformity.

Note that lambda is utterly useless here, be it for one-liners or not.
Alex

[Brian van den Broek]

Fernando Perez said unto the world upon 2004-12-23 14:42:

Alex Martelli wrote:

I don't know what it IS about lambda that prompts so much dubious to
absurd use, but that's what I observed. I don't know if that plays any
role in Guido's current thinking, though -- I have no idea how much
"dubious Python" he's had to struggle with.

Just a side comment, unrelated to the lambda issue: it just occurred to me that
it might be very useful to have a collection of 'dubious python' available
somewhere. Just as it is great for everyone to see good code in action, it is
equally enlightening to see examples of bad practices (preferably with an
explanation of why they are bad and the good alternatives).

I suspect after your CB2 experience, you are in a uniquely well-qualified
position to have such a collection handy. Whether you feel inclined to spend
the necessary time assembling it for public consumption is a different
story :) But I think it would be a very valuable resource, and a great way to
point newbies to 'mandatory reading' before they travel down the same blind
alleys for the n-th time.

Cheers, and happy holidays,

f

Hi all,

+1

I would find this really useful!

I'm much more likely to be among the benefited than the benefactors.
This could be a lot of work for one person. Thus, it seems like a good
thing for a wiki, so as to spread the weight around. With that in mind,
I created <http://www.python.org/moin/DubiousPython>. I hope this seems
like a good idea to others, particularly those more able to extend it
than I. (I'd also be grateful if others could remove any feet than I
might have inadvertently put into my mouth on the wiki page.)

Best to all,

Brian vdB