Securing a future for anonymous functions in Python

[Terry Reedy]

Can I ask what the objection to lambda is?
1) Is it the syntax?
2) Is it the limitation to a single expression?
3) Is it the word itself?

Depending on the person, any of the 3. Plus add
4) The constant complaints re: 2)

I can sympathise with 1 and 2 but the 3rd seems strange since a
lambda is a well defined name for an anonymous function used in
several programming languages and originating in lambda calculus
in math.

And that is why 'lambda' is wrong -- in Python, it is only an abbreviation
for a restricted group of def statements, which is *not* its 'well defined'
usage. Hence complaints re 2. If the syntax were def x: x + 2, etc, I
suspect the complaints would be far fewer.

For some new programmers, 'lambda' is as meaningless as elle*. All other
Python keywords are English words or obvious abbreviations thereof.

So why not retain the name lambda but extend or change the syntax
to make it more capable rather than invent a wholly new syntax
for lambdas?

That you suggest this illustrates, to me, what is wrong with the name ;-)

Terry J. Reedy

* The Spanish name for the letter 'll', pronounced el-yea, which comes
after 'l' in their alphabet.

 

[Alan Gauld]

used, but there are people who do not like "lambda":
http://lambda-the-ultimate.org/node/view/419#comment-3069
The word "lambda" is meaningless to most people. Of course so is "def",
which might be why Guido van Robot changed it to "define":
http://gvr.sourceforge.net/screen_shots/

The unfamiliar argument doesn't work for me. After all most
people are unfamiliar with complex numbers (or imaginary) numbers
but python still provides a complex number type. Just because the
name is unfamiliar to some doesn't mean we shouldn't use the
term if its the correct one for the concept.

Hopefully anyone who wants to use anonymous functions will know
that such are called lambdas and hopefully will have studied
lambda calculus to at least some level - certainly CS majors and
software engineering types should have...

Python is easier for beginners to learn than other mainstream
programming languages

Absolutely, but it has to decide (and soon I think) how important
that role is in the development of the language. Many of the more
recent features are beginner hostile - slots, properties, meta
classes, decorators etc... So is Python going to consciously try
to remain beginner friendly (which it remains by simply ignoring
the newer fatures!) or deliberately go for the "fully featured"
general purpose audience?

Yes, I agree, and either keep the "lambda" keyword or else reuse the
"def" keyword for anonymous methods. See this page Steven Bethard
created: http://www.python.org/moin/AlternateLambdaSyntax

I agree, I'm much more concerned about the idea of losing
anonymous functions (aka lambdas) than about losing the name
lambda, its just that the name is so descriptive of what it does!
( In fact it was seeing the name lambda appearing in a Lisp
programme I was reading that got me started in Lambda calculus
many years ago...)

By the way, you've done great work with your learning to program site
and all the help you've given on the python-tutor list:

Aw shucks! Thanks ;-)

Alan G.
Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld

 

[Anna]

Okay, I tried to post this previously but ran into the new Google
groups system which appears to have sent my original response into the
ether... Oops. Trying again.

Can I ask what the objection to lambda is?
1) Is it the syntax?
2) Is it the limitation to a single expression?
3) Is it the word itself?

I can sympathise with 1 and 2 but the 3rd seems strange since a
lambda is a well defined name for an anonymous function used in
several programming languages and originating in lambda calculus
in math. Lambda therefore seems like a pefectly good name to
choose.

So why not retain the name lambda but extend or change the syntax
to make it more capable rather than invent a wholly new syntax
for lambdas?

Slightly confused, but since I only have time to read these
groups regularly when I'm at home I have probably missed the bulk
of the discussion over the years.

Alan G.
Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld

Hi Alan:

Having taken some calculus (derivatives, limits, some integrals) but
never even heard of lambda calculus, to me, lambda means absolutely
NOTHING. Less than nothing.

Actually, in my encounters with others code in Python (including
reading near 1000 recipes for the recent edition of the Cookbook), what
I've discovered is that what lambda mostly means to me is:
"I don't wanna write clear, elegant Python - I wanna write fancy,
clever, obfuscated code, and lambda lets me do that!"

I've seen maybe 1 case in 10 where lambda appears, to me, to allow
clearer, cleaner code than defining a function. Most cases-it's an
ugly, incomprehensible hack.

So, if people really need anonymous functions in Python (and
apparently, they do), then at least lets get a word that actually
*means* something. Every other word in Python has an obvious meaning.
lambda doesn't.

So, I guess I don't like the word itself - any more than I like how
it's (mostly) used.

Anna Martelli Ravenscroft

 

[Paul Rubin]

Having taken some calculus (derivatives, limits, some integrals) but
never even heard of lambda calculus, to me, lambda means absolutely
NOTHING. Less than nothing.

Lambda calculus is from mathematical logic, but more to the point
"lambda" has been the term used in Lisp for this operation since time
immemorial. Since the kinds of programmers who want to use anonymous
functions have probably been exposed to Lisp at one time or another,
"lambda" should not cause any confusion.

 

[Steve Holden]

Lambda calculus is from mathematical logic, but more to the point
"lambda" has been the term used in Lisp for this operation since time
immemorial. Since the kinds of programmers who want to use anonymous
functions have probably been exposed to Lisp at one time or another,
"lambda" should not cause any confusion.

That's probably not the most enthusiastic evangelical approach to
functional programming I've ever heard

Perhaps what we really need is a good Lisp subsystem for Python?

regards
Steve

 

[Paul Rubin]

Perhaps what we really need is a good Lisp subsystem for Python?

I've thought the other way around, it would be nice to have a Python
subsystem for Lisp.

 

[Jacek Generowicz]

Having taken some calculus (derivatives, limits, some integrals) but
never even heard of lambda calculus, to me, lambda means absolutely
NOTHING. Less than nothing.

And before you took calculus, the chances are that derivatives, limits
and integrals meant less than nothing to you.

But now, I am quite sure, you know that in Python lambda is a keyword
which creates anonymous functions. Now that you know what lambda does,
what's the problem with it? (It certainly doesn't mean "Less than
nothing" to you now.)

So, I guess I don't like the word itself

Fair enough. I guess there are people out there who might have a
distaste for the word "class" or "def" or any of the other words which
are keywords in Python.

Every other word in Python has an obvious meaning. lambda doesn't.

Obvious to whom?

The meaning of every word is obvious, once you have been taught it;
and a complete mystery if you have not.

What do you make of "seq[2:-2]"? It means "less than nothing" to the
uninitiated. Just like lambda.

Getting students in my Python courses to understand "seq[2:-2]" takes
about as much (maybe even a bit more) effort as getting them to
understand lambda[*]. But once they have been taught these features,
they can handle them just fine.


[*] Funnily enough, getting them to understand that "lambda x: fn(x)"
is just a very silly way of writing "fn", can be quite a struggle
at times ... but that's probably a consequence of the context in
which lambda is introduced.

 

[Steven Bethard]

The unfamiliar argument doesn't work for me. After all most
people are unfamiliar with complex numbers (or imaginary) numbers
but python still provides a complex number type. Just because the
name is unfamiliar to some doesn't mean we shouldn't use the
term if its the correct one for the concept.

I'm not sure this is really a fair comparison. What's the odds that if
you're unfamiliar with complex numbers that you're going to have to read
or write code that uses complex numbers? Probably pretty low. I don't
think I've ever had to read or write such code, and I *do* understand
complex numbers. Lambdas, on the other hand, show up in all kinds of
code, and even though I hardly ever use them myself, I have to
understand them because other people do (over-)use them.

Steve

 

[Nick Coghlan]

[*] Funnily enough, getting them to understand that "lambda x: fn(x)"
is just a very silly way of writing "fn", can be quite a struggle
at times ... but that's probably a consequence of the context in
which lambda is introduced.

If you genuinely taught them that, you may have done them a disservice:

Py> def f(x):
.... print x
....
Py> f1 = f
Py> f2 = lambda x: f(x)
Py> f1("hi")
hi
Py> f2("hi")
hi
Py> def f(x):
.... print x * 2
....
Py> f1("hi")
hi
Py> f2("hi")
hihi

Cheers,
Nick.

 

[Nick Coghlan]

Lambda calculus is from mathematical logic, but more to the point
"lambda" has been the term used in Lisp for this operation since time
immemorial.

I think that's part of the problem though - people familiar with lambda calculus
and Lisp's lambdas want Python's lambdas to be equally capable, and they just
plain *aren't*.

If you have a complex function, the Pythonic way is to give it a meaningful
name. Having a way to defer evaluation of a simple expression *is* quite handy,
but 'lambda' is the wrong name for it - the parallels to lambda calculus and
Lisp's lambda functions are likely to be misleading, rather than helpful.

Add in the fact that there are many, many Python programmers with non-CS
backgrounds, and the term 'lambda' sticks out like a sore thumb from amongst
Python's other English-based keywords. 'def' is probably the second-most cryptic
when you first encounter it, but it is a good mnemonic for "define a function",
so it's still easy to parse. "Lambda is the term mathematicians use to refer to
an anonymous function" is nowhere near as grokkable

For me, the alternative syntax discussion is based on 3 of the 4 mentioned reasons:

1. The syntax
I don't like re-using colons as something other than suite delimiters - it
breaks up the affected expression too much (particularly function calls). Code
with dict literals inside function calls bugs me for the same reason (it's OK
when the literal is separated out into an assignment statement for the dict).
It's also too easy to write lambdas which look ambiguous, even though they
technically aren't.
Finally, Python has a reputation as "executable pseudocode". Lambda
expressions don't read like any sort of psuedocode you're likely to see outside
a maths department.

2. The limitation to a single expression
I consider this no more of a problem than the restriction to a single
expression in the main loop of a generator expression or a list comprehension.
When those get too complicated, you switch to using a real for loop somewhere.
Deferred expressions are no different - when the guts get too complicated,
switch to a named function.

3. The word 'lambda' itself
This _is_ one of my objections for the reasons stated above: for people
unfamiliar with the term, they don't know what it is; for people familiar with
the term, it isn't what they think it should be.
Python already has a perfectly good keyword for functions, which has the
additional virtue of being half the length of lambda (this matters, since this
is a keyword that gets embedded in expressions - all the other keywords
currently in that category are three letters or less: and, or, is, in, for)

4. People complaining about 2
Oh hell yes, this bugs me. And I think changing the syntax and calling them
"deferred expressions" instead of "lambdas" would go a long way towards
eliminating the griping.

Cheers,
Nick.

 

[Jacek Generowicz]

[*] Funnily enough, getting them to understand that "lambda x: fn(x)"
is just a very silly way of writing "fn", can be quite a struggle
at times ... but that's probably a consequence of the context in
which lambda is introduced.

If you genuinely taught them that, you may have done them a disservice:

Yes, I was wondering whether I should add lots of caveats to the above.

Py> def f(x):
... print x
...
Py> f1 = f
Py> f2 = lambda x: f(x)
Py> f1("hi")
hi
Py> f2("hi")
hi
Py> def f(x):
... print x * 2
...
Py> f1("hi")
hi
Py> f2("hi")
hihi

There are far less contrived situations in which my original statement
(taken at face value) is wrong. Functions with optional arguments, for
example.

What actually happens is that some of them end up writing:

lambda x: int(x)

in a situation where they want to specify something which will perform
conversions of the type:

"123" -> 123

ie, string to integer conversions.

Usually one or two have trouble grasping that "int" would be perfectly
adequate in this situation.

 

[Nick Coghlan]

Yes, I was wondering whether I should add lots of caveats to the above.

I thought that might be the case. When teaching, I guess I can understand the
need to avoid "well, technically, this isn't always true". It sounds like the
students were having a tough enough time of it already

Usually one or two have trouble grasping that "int" would be perfectly
adequate in this situation.

The ability to pass around functions at run-time was probably the hardest thing
to get my head around when I started with Python, after a history of working in
languages where "the compiler knows about types and functions, and the runtime
knows about variables and instances".

Cheers,
Nick.

 

[Donn Cave]

Hm, I should have been more clear that I'm inferring this from things
that others have said about lambdas in other languages; I'm sadly
rather language-deficient (especially as regards *worthwhile*
languages) myself. This particular impression was formed from a
recent-ish thread about lambdas....

http://groups-beta.google.com/group/comp.lang.python/messages/1719ff05118c4a71
,7323f2271e54e62f,a77677a3b8ff554d,844e49bea4c53c0e,c126222f109b4a2d,b1c962739
0ee2506,0b40192c36da8117,e3b7401c3cc07939,6eaa8c242ab01870,cfeff300631bd9f2?th
read_id=3afee62f7ed7094b&mode=thread

(line-wrap's gonna mangle that, but it's all one line...)

Looking back, I see that I've mis-stated what I'd originally
concluded, and that my original conclusion was a bit questionable to
begin with. In the referenced thread, it was the O.P.'s assertion
that lambdas made higher-order and dynamic functions possible. From
this, I inferred (possibly incorrectly) a different relationship
between functions and lambdas in other (static) languages than exists
in Python.

One could easily be led astray by that post. He may be right
in some literal sense about "the true beauty of lambda function",
inasmuch as beauty is in the eye of the beholder, but in practical
terms, functions are functions.

I took this up on comp.lang.functional some time back. I rewrote
a well known piece of Haskell (State monad), moving functions from
lambda expressions to named function declarations in a "where"
clause and I think undisputably making it easier to understand,
and I asserted that this is representative of the general case -
lambda is a non-essential feature in Haskell. I don't know if
anyone was persuaded, but I didn't see any counter-arguments either.

But of course even if I'm right about that, it doesn't mean the
feature should be stripped from Haskell, that would be an atrocity.
It may not be essential, but it's eminently useful and natural.

Is it useful and natural in Python? Is it worth breaking code over?
Why do we even bother to discuss this here? There aren't good answers
to those questions.

Donn Cave, (e-mail address removed)

 

[Paul Rubin]

Add in the fact that there are many, many Python programmers with
non-CS backgrounds, and the term 'lambda' sticks out like a sore thumb
from amongst Python's other English-based keywords. 'def' is probably
the second-most cryptic when you first encounter it, but it is a good
mnemonic for "define a function", so it's still easy to parse. "Lambda
is the term mathematicians use to refer to an anonymous function" is
nowhere near as grokkable

Richard Feynman told a story about being on a review committee for
some grade-school science textbooks. One of these book said something
about "counting numbers" and it took him a while to figure out that
this was a new term for what he'd been used to calling "integers".

"Integer" is a math term but I think that if we need to use the
concept of integers with someone unfamiliar with the term, it's best
to just introduce the term and then use it, rather than make up new
terminology like "counting numbers" even if those words sound more
like conversational English.

For the same reason I don't have any problem with "lambda", though
it's not that big a deal.

I also just can't believe that Pythonistas keep getting into these
arguments over whether lambda is too confusing, while at the same time
there's no such discussion over far more abstruse Python features like
metaclasses.

 

[Bengt Richter]

[*] Funnily enough, getting them to understand that "lambda x: fn(x)"
is just a very silly way of writing "fn", can be quite a struggle
at times ... but that's probably a consequence of the context in
which lambda is introduced.

Actually, it may _usually_ be silly, but it could be a way of deferring
a name lookup instead of using the current binding of a name:
this updated bar was picked up by silly lambda

Regards,
Bengt Richter

 

[Bengt Richter]

Richard Feynman told a story about being on a review committee for
some grade-school science textbooks. One of these book said something
about "counting numbers" and it took him a while to figure out that
this was a new term for what he'd been used to calling "integers".

"Integer" is a math term but I think that if we need to use the
concept of integers with someone unfamiliar with the term, it's best
to just introduce the term and then use it, rather than make up new
terminology like "counting numbers" even if those words sound more
like conversational English.

<rant>
It's an example of the educational establishment's conspiracy to keep
children from too quickly outshining teachers who feel threatened by raw
intelligence rather than elated at the opportunity to help it form.
Forcing kids to learn a throwaway baby-goo language before they
get the real thing is a kind of abuse IMO.

For the same reason I don't have any problem with "lambda", though
it's not that big a deal.

I also just can't believe that Pythonistas keep getting into these
arguments over whether lambda is too confusing, while at the same time
there's no such discussion over far more abstruse Python features like
metaclasses.

Some things are considered to be behind the pythonostasis and only for the priests? ;-)

Regards,
Bengt Richter

 

[Jeff Shannon]

Richard Feynman told a story about being on a review committee for
some grade-school science textbooks. One of these book said something
about "counting numbers" and it took him a while to figure out that
this was a new term for what he'd been used to calling "integers".

With all due respect to Richard Feynman, I'd have thought that
"counting numbers" would be non-negative integers, rather than the
full set of integers... which, I suppose, just goes to show how
perilous it can be to make up new, "more natural" terms for things.

Jeff Shannon
Technician/Programmer
Credit International

 

[Alan Gauld]

complex numbers. Lambdas, on the other hand, show up in all kinds of
code, and even though I hardly ever use them myself, I have to
understand them because other people do (over-)use them.

That's a fair point I suppose but I still don't see much point in
introducing new names and syntaxes when the existing name is a
sensible one, even if unfamiliar to many. After all it works in
Lisp and Haskell - Haskell even uses Lambda as its emblem...

And besides it may just encoursage some to go and explore Lambda
calculus, it did for me... And my programing improved enormously
as a result. So maybe having the name as a stimulant to research
is a good thing...

OTOH I do accept the point made by another poster that Pythons
single expression limitations mean that they are a poor imitation
of lambdas in other languages. And provided I get some kind of
anonymous code block to pass around I don't care too much if the
name lambda disappears, provided the concept remains! And the
syntax is reasonably simple to use where lambdas get used now.

(Without lambdas of any kind I might finally make the jump
to Ruby that I've been toying with for a while but I just hate
those Perl-like @ symbols...)

<OT::Aside>
We often see people stating that programming shouldn't be called
a science because there is no mathematical basis, such claimants
usually haven't seen Predicate or Lambda calculus. I know, I used
to be in that category and while I don't explicitly use either
when programming (or only rarely) awareness of the principles
suddenly made a lot of the "rules of programming" that I'd been
taught make perfect sense (no side-effects, avoid globals, etc)
Its like the fact that I rarely use Maxwell's equations when
designing electronic circuits - but its nice to
know what the underlying theory is actually based on!
</Aside>

All IMHO of course!

Alan G.
Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld

 

[Terry Hancock]

With all due respect to Richard Feynman, I'd have thought that
"counting numbers" would be non-negative integers, rather than the
full set of integers... which, I suppose, just goes to show how
perilous it can be to make up new, "more natural" terms for things.

Speaking of "natural", I think "counting numbers" would indeed be
the "natural numbers" 1,2,3, ...

So, yeah, I agree. Jargon definitely has its place: I once told a colleague
(in an effort to avoid jargon) that one star was "faster" than another star.

Only after registering his incomprehension, did I really think about the
fact that that had at least 4 or 5 possible meanings (in fact, I meant that
the frequency of its periodic change in radial velocity was higher -- but
I could've meant that it was receeding faster, had a higher amplitude of
radial velocity change, etc.).

I think "lambda" is fine. Basically if you find you need one, you probably
ought to be using the CS term anyway. It would make looking up the
theory that much easier, anyway.

Cheers,
Terry

 

[=?ISO-8859-1?Q?BJ=F6rn_Lindqvist?=]

The more features a language has, the harder it becomes to learn. An
example of that is C++ which has almost everything. Classes, structs,
templates, strange keywords that noone uses like auto, inline const,
passing by reference/value, enum, union, lots of macros, multiple
inheritance, namespaces etc. I'll bet that you could shave off 50% of
C++'s features and it would still be 95% as usable[*].

Judging by the number of PEP proposals and syntax additions that
appear on the mailing list every day Python could some day become as
bloated. We don't want that, do we? So how do we avoid feature bloat?:

1. We stop adding features, either now or at some point in the future.
2. We remove some features.

Either way we have to put a limit on the number of features we want
Python to have. Let's call that number X where X is a number much
smaller than infinity. With a set limit, the discussion becomes "which
features should be selected for use in Python?" instead of "should
this feature be added/removed?" Personally, I don't care either way if
lambda is removed or retained, but I would much rather have the "with"
keyword someone proposed, do-while loops or whatever. I think there
are way too many good features out there just waiting to take lambdas
place.

* - Please don't ask me to make that bet.