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.

[Steve Holden]

Aahz wrote:

In article <ma************ *************** ***********@pyt hon.org>,
Fredrik Lundh <fr*****@python ware.com> wrote:

func(*arg) instead of apply() is a step back -- it hides the fact
that functions are objects, and it confuses the heck out of both
C/C++ programmers and Python programmers that understand the "def
func(*arg)" form, because it looks like something it isn't (there's a
false symmetry between the call-form and the def-form).

For me, it works the other way around, but I can see how you perceive it
that way.

and I still do enough 1.5.2-programming to use "x = x + y"; when I find
myself in a situation where my code would benefit a lot from being able
to write "x += y" instead, I go back and fix the design.

Okay, it wasn't clear in your original post that you're still stuck with
1.5.2. That makes a huge difference in the convenience of newer
features.

I haven't corresponded specifically with Fredrik about this, bit I get
the impression he *chooses* to continue to produce 1.5.2-compatible
products. I for one, having suffered at the hands of modules that
*claim* 1.5.2 compatibility (and then screw you by using dict()!),
appreciate the time he takes to do so.

A summary of how to maintain such compatibility might make Python apps
more accessible - how many of us can say that our code would run on a
Red Hat 7 system any more? The sad thing is that it's often fairly
trivial changes that remove backwards-compatibility.

string methods are nice, but nothing groundbreaking, and their niceness
is almost entirely offset by the horrid "".join(seq ) construct that
keeps popping up when people take the "the string module is deprecated"
yada yada too seriously. and what do the python-devers do? they add a
"sum" built-in, but no "join"? hello?

Well, I guess we have to accept that not every change to the language is
going to be well-thought-out and completely desirable.
While I'm in complete agreement about the "".join() construct on the
basis of looks, I have come to appreciate the fact that I *never* mess up
the order of arguments any more.

Personally that's one of the changes I managed to take in my stride, and
I've never really felt it was a biggie. Maybe my code is just so ugly
that a little extra ugliness isn't noticeable?

horses-for-courses-ly y'rs - steve
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
Holden Web LLC [phone] [phone]

[Cameron Laird]

In article <1g************ *************** @yahoo.com>,
Alex Martelli <al*****@yahoo. com> wrote:

<ta********@gm ail.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.

[Cameron Laird]

In article <ma************ *************** ***********@pyt hon.org>,
Craig Ringer <cr***@postnews papers.com.au> wrote:

[Craig Ringer]

On Wed, 2004-12-29 at 02:08, Cameron Laird wrote:

In article <ma************ *************** ***********@pyt hon.org>,
Craig Ringer <cr***@postnews papers.com.au> wrote:
.
.
.

IMO the reference behaviour of functions in the C API could be
clearer. [snip] . .
.
This is a sensitive area for me, too. I'd welcome insight
on how to think about this. If Pythonia were a better place
in this regard, how would it be? Reference documents that
more transparently define reference behavior?

I think the current documentation does a fairly good job of that when
describing how to treat the return values of the various functions, but
a much poorer one when covering their arguments.
A convention for API names that reveals reference characteristics ?

That is what I'd lean towards personally... but of course there's
duplication and compatibility to be considered.

--
Craig Ringer