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)(someOtherValue)

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.

[Andrew Dalke]

Terry Reedy wrote:

Ok, add 'assuming that func and args are a valid callable and sequence
respectively.' Error messages are not part of the specs, and may change
for the same code from version to version.
While true, the difference in error messages suggests that the
two approaches use slightly different and possibly exploitable
mechanisms.
To be equivalent to len(*blah), this should be apply(len, blah), no *.

Oops. Here's one that really works. I have an idea of why
there's a difference but would rather someone explain it to me.

import traceback

def YieldTest():
yield "Test"

class Blah:
__len__ = None
__iter__ = YieldTest().__iter__

func = len
args = Blah()

try:
print "apply", apply(func, args)
except TypeError, err:
print "does not work:", err
try:
print "call", func(*args)
except TypeError, err:
print "does not work:", err

The output from running it under Python 2.3 is

apply 4
call does not work: len() takes exactly one argument (0 given)

If I make Blah be a new-style class (ie "class Blah(object):")
I get the opposite success behavior:

apply does not work: apply() arg 2 expected sequence, found Blah
call 4

Andrew
da***@dalkescientific.com

[Nick Coghlan]

Python 2.4 interactive session:
Py> class Blah:
.... def __iter__(self):
.... yield "Test"
....
Py> args = Blah()
Py> apply(len, args)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: apply() arg 2 expected sequence, found instance
Py> len(*args)
4
Py> class Blah(object):
.... def __iter__(self):
.... yield "Test"
....
Py> args = Blah()
Py> apply(len, args)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: apply() arg 2 expected sequence, found Blah
Py> len(*args)
4
And you're right, there is a behavioural difference - apply() expects a real
sequence, whereas the extended function call syntax accepts any iterable.

However, there's also a bug in your demo code:

Py> def YieldTest():
.... yield "Test"
....
Py> x = YieldTest().__iter__
Py> list(x())
['Test']
Py> list(x())
[]

Your failing case with len(*args) was due to the iterator having already been
consumed :)

Cheers,
Nick.
--
Nick Coghlan | nc******@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net

[Andrew Dalke]

Nick Coghlan wrote:

And you're right, there is a behavioural difference - apply() expects a real
sequence, whereas the extended function call syntax accepts any iterable.

However, there's also a bug in your demo code:

I guess I must be getting over this cold -- I'm only 1/2 wrong
this time. :)

Andrew
da***@dalkescientific.com

[Aahz]

In article <ma**************************************@python.o rg>,
Fredrik Lundh <fr*****@pythonware.com> wrote:

(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...)

Hmmm... I find code much more readable and writable now that apply() is
going away. And unless you mean "generator" to include iterators in
general, I believe that iterators are another critical addition.

I'm surprised that you don't include garbage collection and augmented
assignment, though. String methods have been a net gain, I think.

Reviewing the various What's New documents, it appears that we really
have been holding the line since 2.2 on language changes.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"19. A language that doesn't affect the way you think about programming,
is not worth knowing." --Alan Perlis

[Fredrik Lundh]

Aahz wrote:

(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...)

Hmmm... I find code much more readable and writable now that apply() is
going away. And unless you mean "generator" to include iterators in
general, I believe that iterators are another critical addition.

I'm surprised that you don't include garbage collection and augmented
assignment, though. String methods have been a net gain, I think.

garbage collection is a CPython implementation detail, not a language
property (it's a nice implementation detail, sure).

and we had iterators before we got the iterator protocol; the protocol made
things slightly more convenient, but it didn't enable you to do anything you
couldn't do before (using __getitem__ instead of __next__). generators are
something entirely different. writing inverted code is hard; yielding is trivial.

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).

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.

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?

</F>

[Just]

In article <ma**************************************@python.o rg>,
"Fredrik Lundh" <fr*****@pythonware.com> wrote:

func(*arg) instead of apply() is a step back
Strongly disagree. I find func(*args) much more readable than
apply(func, args).
-- it hides the fact that functions are objects,
What does this have to do with anything?
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).
What's false about the symmetry?

Call: you supply a sequence of args
Def: you receive a sequence of args

Lovely.
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.

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?

That's what you get for unsubscribing ;-)

Just

[Aahz]

In article <ma**************************************@python.o rg>,
Fredrik Lundh <fr*****@pythonware.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.
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?

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.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"19. A language that doesn't affect the way you think about programming,
is not worth knowing." --Alan Perlis

[Dima Dorfman]

On 2004-12-26, Fredrik Lundh <fr*****@pythonware.com> wrote:

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?

I happen to not mind the ''.join syntax, but if I did, I would use

str.join('', seq)

which is just like a join builtin except that it's not as easy to make
it work on pre-string-method Pythons.

[Mike Meyer]

aa**@pythoncraft.com (Aahz) writes:

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.

Yeah. When I needed joinable arrays of strings in Eiffel, I added them
to the ARRAY[STRING] class. array.join("") is *much* saner looking.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Fredrik Lundh]

Dima Dorfman wrote:

I happen to not mind the ''.join syntax, but if I did, I would use

str.join('', seq)

which is just like a join builtin except that it's not as easy to make
it work on pre-string-method Pythons.

just like join, except that it isn't:

string.join(seq, sep) u'axbxc' sep.join(seq) u'axbxc' str.join(sep, seq)

Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: descriptor 'join' requires a 'str' object but received a 'unicode'

</F>

[Steve Holden]

Aahz wrote:

In article <ma**************************************@python.o rg>,
Fredrik Lundh <fr*****@pythonware.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********@gmail.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**************************************@python.o rg>,
Craig Ringer <cr***@postnewspapers.com.au> wrote:

[Craig Ringer]

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

In article <ma**************************************@python.o rg>,
Craig Ringer <cr***@postnewspapers.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