Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > better lambda support in the future?

Reply
Thread Tools

better lambda support in the future?

 
 
Jason Zheng
Guest
Posts: n/a
 
      12-17-2004
I'm wondering why python still has limited lambda support. What's
stopping the developers of python to support more lisp-like lambda function?
 
Reply With Quote
 
 
 
 
elbertlev@hotmail.com
Guest
Posts: n/a
 
      12-17-2004
Lambda functions will become obsolette in the nearest future. This is
the PLAN.

 
Reply With Quote
 
 
 
 
Steven Bethard
Guest
Posts: n/a
 
      12-17-2004
Jason Zheng wrote:
> I'm wondering why python still has limited lambda support. What's
> stopping the developers of python to support more lisp-like lambda
> function?


This comes up every few weeks on the list. If you haven't already,
check the archives in Google for 'anonymous def' or 'anonymous
function'. The usual response to this question is something along the
lines of "if it's good enough to create a function for, it's good enough
to name".

One of the other big reasons for this type of proposal never making it
far is that, so far, no one has found a syntax that everyone (or even
most people) like. You end up with things like:

x = func or lambda x, y:
# body of lambda func
# indented here

or

x = func or lambda x, y:
# body of lambda func
# indented here

or

x = func or lambda x, y {
# body of lamda func indented
# however you want...
}

or any thousand other varieties.

Even if you could settle the syntax issue, once you've decided that you
really do need a true block in an anonymous function, you're not really
saving much space by not declaring it:

def f(*args):
# body line 1
# body line 2
# ...
# body line N
x = func or f

v.s.

x = func or lambda *args:
# body line 1
# body line 2
# ...
# body line N

so, you save a single line, which is only 1 Nth of the size of your
function (where N is the number of lines in your function body). For a
single or double line function, these savings may be more substantial,
but chances are if your function is only one or two lines, it can be
written as an expression anyway (e.g. using LCs or GEs)...


Do check the archives -- there are a lot of discussions on this topic,
but hopefully the brief commentary above will give you something of an
overview.

Steve
 
Reply With Quote
 
Fredrik Lundh
Guest
Posts: n/a
 
      12-17-2004
Steven Bethard wrote:

> Even if you could settle the syntax issue, once you've decided that you really do need a true
> block in an anonymous function, you're not really saving much space by not declaring it:
>
> def f(*args):
> # body line 1
> # body line 2
> # ...
> # body line N
> x = func or f
>
> v.s.
>
> x = func or lambda *args:
> # body line 1
> # body line 2
> # ...
> # body line N


you meant:

def x(*args):
# body line 1
# body line 2
# ...
# body line N

v.s.

x = func or lambda *args:
# body line 1
# body line 2
# ...
# body line N

right?

</F>



 
Reply With Quote
 
Jason Zheng
Guest
Posts: n/a
 
      12-17-2004
Steven Bethard wrote:
> Jason Zheng wrote:
>
>> I'm wondering why python still has limited lambda support. What's
>> stopping the developers of python to support more lisp-like lambda
>> function?

>
>
> This comes up every few weeks on the list. If you haven't already,
> check the archives in Google for 'anonymous def' or 'anonymous
> function'. The usual response to this question is something along the
> lines of "if it's good enough to create a function for, it's good enough
> to name".


The true beauty of lambda function is not the convenience of creating
functions without naming them. Lambda constructs truly enables
higher-order function. For example, I can create a function A that
returns a function B that does something interesting according to the
arguments that I pass to function A.
 
Reply With Quote
 
Steven Bethard
Guest
Posts: n/a
 
      12-17-2004
Fredrik Lundh wrote:
> Steven Bethard wrote:
>
>
>>Even if you could settle the syntax issue, once you've decided that you really do need a true
>>block in an anonymous function, you're not really saving much space by not declaring it:
>>
>>def f(*args):
>> # body line 1
>> # body line 2
>> # ...
>> # body line N
>>x = func or f
>>
>>v.s.
>>
>>x = func or lambda *args:
>> # body line 1
>> # body line 2
>> # ...
>> # body line N

>
>
> you meant:
>
> def x(*args):
> # body line 1
> # body line 2
> # ...
> # body line N
>
> v.s.
>
> x = func or lambda *args:
> # body line 1
> # body line 2
> # ...
> # body line N
>
> right?


You're welcome to name the function whatever you want -- notice in my
example that the function is used in the statement:

x = func or f

If you'd prefer the statement to read:

x = func or x

that's also fine. Depends on what exactly 'x' is, and whether or not it
really makes sense for the function I called 'f' to have the same name
as the variable called 'x'. It certainly may, but since I wasn't giving
real code, I didn't want to commit to that.

Perhaps a better example would have been something along the lines of:

dict(a=lambda *args:
# body 1
,
b=lambda *args:
# body 2
,
c=lambda *args:
# body 3
)[s](values)

v.s.

def a_func(*args):
# body 1
def b_func(*args):
# body 2
def c_func(*args):
# body 3
dict(a=a_func, b=b_func, c=c_func)[s](values)

where it's clear that I'm trying to use lambdas where expressions are
required.

I assume that the point you were trying to make is that:

def f(*args):
return expr

is equivalent to

f = lambda *args: expr

?

Steve
 
Reply With Quote
 
Michael DeHaan
Guest
Posts: n/a
 
      12-17-2004
True enough, but suppose you want a hash of anonymous functions as
opposed to just a lexical? This is where lambas are nice to have.
Totally agreed about a small use here and there, but they do have some
use in dispatch tables, as they are a lot easier to read sometimes
than very long case statements. Of course, this would require
multi-line lambdas to exist...

--Michael

> I assume that the point you were trying to make is that:
>
> def f(*args):
> return expr
>
> is equivalent to
>
> f = lambda *args: expr
>
> ?
>
> Steve
> --
> http://mail.python.org/mailman/listinfo/python-list
>

 
Reply With Quote
 
Fredrik Lundh
Guest
Posts: n/a
 
      12-17-2004
Steven Bethard wrote:

> You're welcome to name the function whatever you want -- notice in my example that the function is
> used in the statement:
>
> x = func or f
>
> If you'd prefer the statement to read:
>
> x = func or x
>
> that's also fine. Depends on what exactly 'x' is, and whether or not it really makes sense for
> the function I called 'f' to have the same name as the variable called 'x'. It certainly may, but
> since I wasn't giving real code, I didn't want to commit to that.


if you write "def f", "f" is a variable, just like "x". "def" is an assignment
statement.

I'm not sure what "func" is supposed to be in your examples...

> I assume that the point you were trying to make is that:
>
> def f(*args):
> return expr
>
> is equivalent to
>
> f = lambda *args: expr
>
> ?


>>> def f():

.... return 1+2
....
>>> g = lambda: 1 + 2
>>> type(f)

<type 'function'>
>>> type(g)

<type 'function'>

>>> import dis
>>> dis.dis(f)

2 0 LOAD_CONST 1 (1)
3 LOAD_CONST 2 (2)
6 BINARY_ADD
7 RETURN_VALUE
>>> dis.dis(g)

1 0 LOAD_CONST 1 (1)
3 LOAD_CONST 2 (2)
6 BINARY_ADD
7 RETURN_VALUE

>>> dir(f)

['__call__', '__class__', '__delattr__', '__dict__', '__doc__', '__get__', '__ge
tattribute__', '__hash__', '__init__', '__module__', '__name__', '__new__', '__r
educe__', '__reduce_ex__', '__repr__', '__setattr__', '__str__', 'func_closure',
'func_code', 'func_defaults', 'func_dict', 'func_doc', 'func_globals', 'func_na
me']
>>> dir(g)

['__call__', '__class__', '__delattr__', '__dict__', '__doc__', '__get__', '__ge
tattribute__', '__hash__', '__init__', '__module__', '__name__', '__new__', '__r
educe__', '__reduce_ex__', '__repr__', '__setattr__', '__str__', 'func_closure',
'func_code', 'func_defaults', 'func_dict', 'func_doc', 'func_globals', 'func_na
me']

>>> f.func_name

'f'
>>> g.func_name

'<lambda>'

</F>



 
Reply With Quote
 
Steven Bethard
Guest
Posts: n/a
 
      12-17-2004
Fredrik Lundh wrote:
> I'm not sure what "func" is supposed to be in your examples...


Just an extra variable used to make sure that the lambda was being used
in a context (i.e. in an expression) where a simple def wouldn't
suffice. If the example is confusing, consider the dict example
instead. It makes it clearer that the lambdas are being used in places
where an expression is required.

Steve
 
Reply With Quote
 
Steven Bethard
Guest
Posts: n/a
 
      12-17-2004
Michael DeHaan wrote:
> True enough, but suppose you want a hash of anonymous functions as
> opposed to just a lexical?


I've seen at least one reasonable example of this kind of thing:

http://mail.python.org/pipermail/pyt...er/245432.html

Though I haven't yet seen an example that actually required lambdas with
blocks...

> Totally agreed about a small use here and there, but they do have some
> use in dispatch tables, as they are a lot easier to read sometimes
> than very long case statements. Of course, this would require
> multi-line lambdas to exist...


Certainly in the example above, I'd be willing to agree that the lambdas
are at least as readable as a buch of def's above would have been. I'm
not sure if multi-line lambdas would be as readable though... It all
depends on what syntax you write them in -- you can see the struggle I
went through in my other message... Where do I put the commas in a
dict? Can't be at the end of the lambda or they turn the last
expression into a tuple... I resorted to putting them on a separate
line, but of course there are other solutions.


If you have a good example of where you'd like to use multi-line
lambdas, in, say, a dispatch table, I'd like to take a look at how you'd
like to write them. I'm not yet convinced that there really is a
readable way to write such things...

Steve
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Type of lambda function returning a lambda function... Haochen Xie C++ 4 03-17-2013 11:23 PM
lambda vs non-lambda proc Steve Dogers Ruby 1 03-30-2009 10:11 PM
Build a Better Blair (like Build a Better Bush, only better) Kenny Computer Support 0 05-06-2005 04:50 AM
Re: Lambda as declarative idiom (was RE: what is lambda used for inreal code?) Roman Suzi Python 13 01-07-2005 09:33 PM
Re: better lambda support in the future? Jp Calderone Python 2 12-18-2004 07:13 AM



Advertisments