Lambda going out of fashion

[Skip Montanaro]

Improving Python (was: Lambda going out of fashion)


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]

Re: Lambda going out of fashion


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@gmail.com]

Re: Lambda going out of fashion

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]

Re: Lambda going out of fashion

tanghaibao@gmai l.com wrote:[color=blue]
> 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.[/color]

I'm not exactly sure what you mean by "flexibilit y"; all of these
examples can be written without lambdas:
[color=blue]
> apply_each = lambda funs, args = []: map(apply, fns, [args]*len(fns))[/color]

def apply_each(fns, args=[]):
return [fn(*args) for fn in fns]
[color=blue]
> bools = lambda lst: mpa(truth, lst)[/color]

def bools(lst):
return [bool(x) for x in lst]
[color=blue]
> bool_each = lambda fns, args = []: bools(apply_eac h(fns, args))[/color]

def bool_each(fns, args=[]):
return bools(apply_eac h(fns, args))
[color=blue]
> conjoin = lambda fns, args = []: reduce(mul, bool_each(fns, args))[/color]

def conjoin(fns, args=[]):
reduce(mul, bool_each(fns, args))
[color=blue]
> all = lambda fns: lambda arg, fns = fns: conjoin(fns, (arg,))[/color]

def all(fns):
def _(arg):
return conjoin(fns, (arg,))
return _
[color=blue]
> both = lambda f,g: all(f(f,g))[/color]

def both(f, g):
return all(f(f,g))
[color=blue]
> all3 = lambda f,g,h: all((f,g,h))[/color]

def all3(f, g, h):
return all((f,g,h))
[color=blue]
> and_ = lambda f,g: lambda x, f=f, g=g: f(x) and g(x)[/color]

def and_(f, g):
def _(x):
return f(x) and g(x)
return _
[color=blue]
> disjoin = lambda fns, args = []: reduce(add, bool_each(fns, args))[/color]

def disjoin(fns, args=[]):
return reduce(add, bool_each(fns, args))
[color=blue]
> some = lambda fns: lambda arg, fns = fns: disjoin(fns, (arg,))[/color]

def some(fns):
def _(arg):
return disjoin(fns, (arg,))
return _
[color=blue]
> either = lambda f,g: some((f,g))[/color]

def either(f, g):
return some((f,g))
[color=blue]
> anyof3 = lambda f,g,h: some((f,g,h))[/color]

def anyof3(f, g, h):
return some((f,g,h))
[color=blue]
> compose = lambda f,g: lambda x, f=f, g=g: f(g(x))[/color]

def compose(f, g):
def _(x):
return f(g(x))
return _
[color=blue]
> compose3 = lambda f,g,h: lambda x, f=f, g=g, h=j: f(g(h(x)))[/color]

def compose3(f, g, h):
def _(x):
return f(g(h(x)))
return _
[color=blue]
> ident = lambda x:x[/color]

def ident(x):
return x


Steve

[tanghaibao@gmail.com]

Re: Lambda going out of fashion

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]

Re: Lambda going out of fashion

tanghaibao@gmai l.com wrote:
[color=blue]
> o Why don't you just say all python can be written in equivalent java,[/color]

your argumentation skills are awesome.

</F>

[Fredrik Lundh]

Re: Lambda going out of fashion

"jfj" wrote:
[color=blue]
> 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.[/color]

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]

Re: Lambda going out of fashion

Robin Becker wrote:[color=blue]
> Alex Martelli wrote:
> .....
>[color=green]
>> By the way, if that's very important to you, you might enjoy Mozart
>> (http://www.mozart-oz.org/)
>>[/color]
> .....very interesting, but it wants to make me install emacs. :([/color]

Apparently you can also use oz with a compiler and runtime engine...see

http://www.mozart-oz.org/documentation/apptut/index.html

Kent

[Alex Martelli]

Re: Lambda going out of fashion

<tanghaibao@gma il.com> wrote:
[color=blue]
> Thanks. :-) Two remarks.
> o One-liner fits the eyes & brains of a portion of people.[/color]

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]

Dubious Python WAS: Re: Lambda going out of fashion

Fernando Perez said unto the world upon 2004-12-23 14:42:[color=blue]
> Alex Martelli wrote:
>
>[color=green]
>>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.[/color]
>
>
> 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[/color]

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

[Skip Montanaro]

Re: Lambda going out of fashion

[color=blue][color=green]
>> readability. Pythonic lambdas are just syntactic sugar in practice,[/color][/color]

Paul> Actually it's the other way around: it's named functions that are
Paul> the syntactic sugar.

While I'm sure it can be done, I'd hate to see a non-trivial Python program
written with lambda instead of def. (Take a crack at pystone if you're
interested.)

Skip

[Fredrik Lundh]

Re: Improving Python (was: Lambda going out of fashion)

Skip Montanaro wrote:[color=blue]
>
> 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"?[/color]

as I've proven from time to time, joining the "et al" and *not* tinkering with
the language doesn't mean that the language stays where it is.

(I've said it before, and I'll say it again: native unicode and generators are
the only essential additions I've seen since 1.5.2, with properties and sub-
classable C types sharing a distant third place. the rest of the stuff has had
zero impact on my ability to write solid code in no time at all, and negative
impact on my ability to download stuff that others have written and expect
it to work in any Python version but the latest...)

</F>

[Fernando Perez]

Re: Lambda going out of fashion

Alex Martelli wrote:
[color=blue]
> 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.[/color]

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

[Terry Reedy]

Re: Lambda going out of fashion


<tanghaibao@gma il.com> wrote in message
news:1103786497 .565595.85070@z 14g2000cwz.goog legroups.com...[color=blue]
> Well, you can say apply() is 'deprecated' now,[/color]

What is deprecated is the spelling, not the concept or functionality.
As far as I know, apply(func, args) is exactly equivalent to func(*args).
If the latter had been invented in the beginning and you had learned it as
Python's spelling of the apply concept, you might never miss the 'apply'
spelling.

Terry J. Reedy

[Andrew Dalke]

Re: Lambda going out of fashion

Terry Reedy wrote:[color=blue]
> As far as I know, apply(func, args) is exactly equivalent to func(*args).[/color]

After playing around a bit I did find one difference in
the errors they can create.
[color=blue][color=green][color=darkred]
>>> def count():[/color][/color][/color]
.... yield 1
....[color=blue][color=green][color=darkred]
>>> apply(f, count())[/color][/color][/color]
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: apply() arg 2 expected sequence, found generator[color=blue][color=green][color=darkred]
>>> f(*count())[/color][/color][/color]
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: len() of unsized object[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]

That led me to the following
[color=blue][color=green][color=darkred]
>>> class Blah:[/color][/color][/color]
.... def __len__(self):
.... return 10
.... def __getitem__(sel f, i):
.... if i == 0: return "Hello!"
.... raise IndexError, i
....[color=blue][color=green][color=darkred]
>>> blah = Blah()
>>> len(*blah)[/color][/color][/color]
6[color=blue][color=green][color=darkred]
>>> apply(len, *blah)[/color][/color][/color]
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: len() takes exactly one argument (6 given)[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]

Is that difference a bug?

Andrew
dalke@dalkescie ntific.com