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.

[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().__i ter__

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***@dalkescie ntific.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().__i ter__
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***@dalkescie ntific.com

[Aahz]

In article <ma************ *************** ***********@pyt hon.org>,
Fredrik Lundh <fr*****@python ware.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**@pythoncra ft.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************ *************** ***********@pyt hon.org>,
"Fredrik Lundh" <fr*****@python ware.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************ *************** ***********@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.
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**@pythoncra ft.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*****@python ware.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**@pythoncraf t.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.or g> 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>