How do I dynamically create functions without lambda?

[Russell]

I want my code to be Python 3000 compliant, and hear
that lambda is being eliminated. The problem is that I
want to partially bind an existing function with a value
"foo" that isn't known until run-time:

someobject.newf unc = lambda x: f(foo, x)

The reason a nested function doesn't work for this is
that it is, well, dynamic. I don't know how many times
or with what foo's this will be done.

Now, I am sure there are a half-dozen ways to do this.
I just want the one, new and shiny, Pythonic way. ;-)

[Kay Schluehr]

Steven D'Aprano wrote:

On Fri, 27 Jan 2006 11:41:56 -0800, Kay Schluehr wrote:

Russell wrote:

I want my code to be Python 3000 compliant, and hear
that lambda is being eliminated. The problem is that I
want to partially bind an existing function with a value
"foo" that isn't known until run-time:

someobject.newf unc = lambda x: f(foo, x)

The reason a nested function doesn't work for this is
that it is, well, dynamic. I don't know how many times
or with what foo's this will be done.

Now, I am sure there are a half-dozen ways to do this.
I just want the one, new and shiny, Pythonic way. ;-)
If you want to code partial application without lambda I recommend
using the code presented in the accepted PEP 309 that will be
implemented in the functional module in Python 2.5.

http://www.python.org/peps/pep-0309.html

Fascinating. A couple of thoughts:

- I really wish that people would make up their minds about what currying
is, and how it differs from partials and closures. If the people who
do know can't agree, how do they expect the rest of us to understand?

If they can't agree they probably don't know ;)

Concepts like "closure" and "currying" are well defined in lambda
calculus and hence in functional programming.
- What, if anything, is the difference between a closure and an iterator?
Is an iterator just a closure wrapped up with an API?

I would expect a closure to be a function with free/unbound variables
that are bound by an enclosing context. In FP slang a function without
any free variables is called a "combinator ". An iterator is a function
related to an abstract data type equipped with a partial order. The
iterator abstracts from the particular ordering scheme and makes the
ADT look like a list. In Python we have a nice correspondence between
generators as implicit defined sequences of yielded values, iterators
that enable uniform access to the values produced by generators and
lists that make the sequence explicit ( if finite ).

Fun with combinators
=============== =======
There are quite interesting relationships deep down in the theory of
computation. For instance understanding recursion in lambda calculus is
not that easy because you cannot simply reintroduce an anonymous
function by the name into its own body. The idea is to create a
fixpoint of a higher order curried function instead. See for example
this curried extension of a factorial:

F = lambda h: lambda n : n<2 and 1 or n*h(n-1)

Now imagine you have a fixpoint fix(F) of F which is again a function
and pass it into F then you will get:

fix(F) = F(fix(F)) = lambda n : n<2 and 1 or n*fix(F)(n-1)

That is fix(F) is actually the searched factorial ! There is a generic
way to create fixpoints of higher order curried functions such as F.
The most popular one is the so called Y-combinator ( not to confuse
with Paul Grahams company ;).

In Python you can write:

Y = lambda g: (lambda f: g(lambda arg: f(f)(arg))) (lambda f: g(lambda
arg: f(f)(arg)))

This serves the purpose. Try Y(F) and see.

Kay

[Steven D'Aprano]

On Sat, 28 Jan 2006 00:13:28 -0800, Kay Schluehr wrote:

[snip lambda calculus stuff]

In Python you can write:

Y = lambda g: (lambda f: g(lambda arg: f(f)(arg))) (lambda f: g(lambda
arg: f(f)(arg)))

This serves the purpose. Try Y(F) and see.

Is any of this stuff maintainable in the real world of IT, where
most programmers don't have computer science degrees? You come along six
months after the project was finished to maintain this code and discover
that the whiz-kid lambda calculus guy never commented anything because
that would detract from the elegance of his one liners; what happens next?

--
Steven.

[Kay Schluehr]

Steven D'Aprano wrote:

On Sat, 28 Jan 2006 00:13:28 -0800, Kay Schluehr wrote:

[snip lambda calculus stuff]

In Python you can write:

Y = lambda g: (lambda f: g(lambda arg: f(f)(arg))) (lambda f: g(lambda
arg: f(f)(arg)))

This serves the purpose. Try Y(F) and see.

Is any of this stuff maintainable in the real world of IT, where
most programmers don't have computer science degrees?

Probably not. But the good thing about Y is that it is in closed form
and the expression is not infinitely long. By the way I have no less a
hard time to read C code with advanced data-structures and many type
casts which is much more likely to happen in the "real world".
From what I've seen the only *practical* purpose fixpoint combinators serve is a kind of recursion "overloadin g". Without modifying F one can
memoize values by adapting the fixpoint combinator. We already know
something similar from the Go4 "command pattern" but there is no
self-referential entanglement and it is less general.
You come along six
months after the project was finished to maintain this code and discover
that the whiz-kid lambda calculus guy never commented anything because
that would detract from the elegance of his one liners; what happens next?

Ask a Scheme guy at LtU. Accuse the original author in Den Haag and if
caught put him to shame by making photos at a dentist. Google for
"lambda calculus Y". Ask someone here at comp.lang.pytho n. Ask your
boss for more time ;)

Kay

[Antoon Pardon]

Op 2006-01-27, Russell schreef <ru************ @hotmail.com>:

I want my code to be Python 3000 compliant, and hear
that lambda is being eliminated. The problem is that I
want to partially bind an existing function with a value
"foo" that isn't known until run-time:

someobject.newf unc = lambda x: f(foo, x)

The reason a nested function doesn't work for this is
that it is, well, dynamic. I don't know how many times
or with what foo's this will be done.
I don't see how dynamic is supposed to contradict with
nested functions. I assume from your tekst that foo
has some parameter-like charateristics. So the following
should work.

def produce(foo):

def func(x):
return f(foo, x)

return func
someobject.newf unc = produce(foo)
This kind of code can be generalized. Look for partial
application or curry.

Now, I am sure there are a half-dozen ways to do this.
I just want the one, new and shiny, Pythonic way. ;-)

The new and shiny, pythonic way depends on what you
really want, your question was a bit vague to answer
that.

--
Antoon pardon

[Alan Morgan]

In article <pa************ *************** *@REMOVETHIScyb er.com.au>,
Steven D'Aprano <st***@REMOVETH IScyber.com.au> wrote:

On Sat, 28 Jan 2006 00:13:28 -0800, Kay Schluehr wrote:

[snip lambda calculus stuff]

In Python you can write:

Y = lambda g: (lambda f: g(lambda arg: f(f)(arg))) (lambda f: g(lambda
arg: f(f)(arg)))

This serves the purpose. Try Y(F) and see.

Is any of this stuff maintainable in the real world of IT, where
most programmers don't have computer science degrees? You come along six
months after the project was finished to maintain this code and discover
that the whiz-kid lambda calculus guy never commented anything because
that would detract from the elegance of his one liners; what happens next?

Excessive cleverness can lead to unmaintainable code. So can excessive stupidity.
Since there are a lot more stupid people than clever people out there I think
the more likely scenario is having to maintain unmaintainable code written by a
complete idiot whose programming knowledge comes solely from books whose titles
end with "In 7 Days".

Oh, and I'd hope that code reviews, etc. would have kept lambda-boy from getting
too far down this path of self invocation.

Alan
--
Defendit numerus

[Alex Martelli]

Alan Morgan <am*****@xenon. Stanford.EDU> wrote:
...

Excessive cleverness can lead to unmaintainable code. So can excessive
stupidity.
+1 QOTW.
Since there are a lot more stupid people than clever people out there I
think the more likely scenario is having to maintain unmaintainable code
written by a complete idiot whose programming knowledge comes solely from
books whose titles end with "In 7 Days".

Disagree -- far more people THINK they're clever, than really ARE
clever. According to a recent article in the Financial Times, over 40%
of a typical financial firm's employees firmly believe they are among
the 5% best employees of the firm -- and the situation, believe me, is
no different in programming.
Alex

[Steve Holden]

Alex Martelli wrote:

Alan Morgan <am*****@xenon. Stanford.EDU> wrote:
...

Excessive cleverness can lead to unmaintainable code. So can excessive
stupidity.

+1 QOTW.

++

Since there are a lot more stupid people than clever people out there I
think the more likely scenario is having to maintain unmaintainable code
written by a complete idiot whose programming knowledge comes solely from
books whose titles end with "In 7 Days".

Disagree -- far more people THINK they're clever, than really ARE
clever. According to a recent article in the Financial Times, over 40%
of a typical financial firm's employees firmly believe they are among
the 5% best employees of the firm -- and the situation, believe me, is
no different in programming.

Just as 85% of drivers believe their skill level is "above average".

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

[Alan Morgan]

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

Alan Morgan <am*****@xenon. Stanford.EDU> wrote:
...

Excessive cleverness can lead to unmaintainable code. So can excessive
stupidity.
+1 QOTW.

import blush

Since there are a lot more stupid people than clever people out there I
think the more likely scenario is having to maintain unmaintainable code
written by a complete idiot whose programming knowledge comes solely from
books whose titles end with "In 7 Days".

Disagree -- far more people THINK they're clever, than really ARE
clever.

No doubt about it, but I don't see how it contradicts my statement.
According to a recent article in the Financial Times, over 40%
of a typical financial firm's employees firmly believe they are among
the 5% best employees of the firm -- and the situation, believe me, is
no different in programming.

I wonder if python, which has a low barrier to entry due to its simple syntax
and general readability, might not have a worse time of this than other languages.

Alan
--
Defendit numerus

[Benji York]

Alex Martelli wrote:

Disagree -- far more people THINK they're clever, than really ARE
clever. According to a recent article in the Financial Times, over 40%
of a typical financial firm's employees firmly believe they are among
the 5% best employees of the firm -- and the situation, believe me, is
no different in programming.

It's apparently no different anywhere:
http://www.phule.net/mirrors/unskilled-and-unaware.html
--
Benji York

[Alex Martelli]

Benji York <be***@benjiyor k.com> wrote:

Alex Martelli wrote:

Disagree -- far more people THINK they're clever, than really ARE
clever. According to a recent article in the Financial Times, over 40%
of a typical financial firm's employees firmly believe they are among
the 5% best employees of the firm -- and the situation, believe me, is
no different in programming.

It's apparently no different anywhere:
http://www.phule.net/mirrors/unskilled-and-unaware.html

Tx. Maybe it's a genetically adaptive trait: the FT points out that
while there is little correlation between an employee's opinion of their
skills, and the employee's actual performance, there IS positive
correlation between said opinion and the employee's career advancement.
One way to explain the correlation is: if you truly (albeit perhaps
mistakenly) believe you're great, you project that and are more likely
to get promotions or raises, than is somebody else, perhaps objectively
better, who's torn by self-doubt and projects THAT.

My working hypothesis would be that this effect would be far stronger in
fields where it's hard to get hard quantitative measures of performance,
so the managers (or clients, etc) rely to a large extent on subjective
judgment which can be influenced by such "projections".. .
Alex