469,304 Members | 2,018 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,304 developers. It's quick & easy.

Securing a future for anonymous functions in Python

GvR has commented that he want to get rid of the lambda keyword for Python 3.0.
Getting rid of lambda seems like a worthy goal, but I'd prefer to see it dropped
in favour of a different syntax, rather than completely losing the ability to
have anonymous functions.

Anyway, I'm looking for feedback on a def-based syntax that came up in a recent
c.l.p discussion:
http://boredomandlaziness.skystorm.n...in-python.html

Cheers,
Nick.

--
Nick Coghlan | nc******@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
Jul 18 '05
76 3415
Nick Coghlan <nc******@iinet.net.au> writes:
Jacek Generowicz wrote:
[*] 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.
Jul 18 '05 #51
Jacek Generowicz wrote:
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.

--
Nick Coghlan | nc******@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
Jul 18 '05 #52
In article <10*************@corp.supernews.com>,
Jeff Shannon <je**@ccvcorp.com> wrote:
....
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/...19ff05118c4a71
,7323f2271e54e62f,a77677a3b8ff554d,844e49bea4c53c0 e,c126222f109b4a2d,b1c962739
0ee2506,0b40192c36da8117,e3b7401c3cc07939,6eaa8c24 2ab01870,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, do**@u.washington.edu
Jul 18 '05 #53
Nick Coghlan <nc******@iinet.net.au> writes:
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.
Jul 18 '05 #54
On 07 Jan 2005 14:38:01 +0100, Jacek Generowicz <ja**************@cern.ch> wrote:
[...]

[*] 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:
def bar(): return 'this is bar' ... def foo(f=bar): print f() ... def bar(): return 'this is updated bar' ... foo() this is bar def foo(f=lambda:bar()): print f() ... foo() this is updated bar def bar(): return 'this updated bar was picked up by silly lambda' ... foo()

this updated bar was picked up by silly lambda

Regards,
Bengt Richter
Jul 18 '05 #55
On 07 Jan 2005 13:24:39 -0800, Paul Rubin <http://ph****@NOSPAM.invalid> wrote:
Nick Coghlan <nc******@iinet.net.au> writes:
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.

<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.
</rant>

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
Jul 18 '05 #56
Paul Rubin wrote:
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

Jul 18 '05 #57
On Fri, 07 Jan 2005 08:44:57 -0700, Steven Bethard
<st************@gmail.com> wrote:
The unfamiliar argument doesn't work for me. After all most
people are unfamiliar with complex numbers (or imaginary) numbers


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
Jul 18 '05 #58
On Friday 07 January 2005 06:12 pm, Jeff Shannon wrote:
Paul Rubin wrote:
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. ;)


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

--
--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks http://www.anansispaceworks.com

Jul 18 '05 #59
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.

--
mvh Björn
Jul 18 '05 #60
Alan Gauld wrote:
On Fri, 07 Jan 2005 08:44:57 -0700, Steven Bethard
<st************@gmail.com> wrote:
The unfamiliar argument doesn't work for me. After all most
people are unfamiliar with complex numbers (or imaginary) numbers


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


Yeah, I personally expect that if GvR doesn't like lambda now, he won't
like any of the new syntaxes either. But I'm in the camp that won't
miss lambda if it's gone, so I'm not too worried. ;)

Steve
Jul 18 '05 #61
On Friday 07 January 2005 01:24 pm, Paul Rubin wrote:
Nick Coghlan <nc******@iinet.net.au> writes:
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.


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

I think we should not try too hard to make everything "English" like. Its a
crappy language anyway (though its the only one I speak good). Matt Neuberg,
in _AppleScript: The Definitive Guide_, refers to "the English-likeness
monster". His example is that instead of

x = 4

you have to say

copy 4 to x

I think every reader of this list would prefer to look at the former.

The point is that once we learn new symbolics of expression, they are as
simple to decipher as plain old English if we format properly and
gIvEnThAtwEiNcLuDEsOmEhElPfUlfORmaTtInGInOuRcOdEFr oMtImEtOtiME.

So I think that being fearful of new additions to the language (read "more
ability for expression") is mainly fear of abuse by poor programmers--and
that is akin to being afraid of the dark.

James

--
James Stroud, Ph.D.
UCLA-DOE Institute for Genomics and Proteomics
611 Charles E. Young Dr. S.
MBI 205, UCLA 951570
Los Angeles CA 90095-1570
http://www.jamesstroud.com/
Jul 18 '05 #62
In article <ma**************************************@python.o rg>,
James Stroud <js*****@mbi.ucla.edu> wrote:
On Friday 07 January 2005 01:24 pm, Paul Rubin wrote:
Nick Coghlan <nc******@iinet.net.au> writes:
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.


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

I think we should not try too hard to make everything "English" like. Its a
crappy language anyway (though its the only one I speak good). Matt Neuberg,
in _AppleScript: The Definitive Guide_, refers to "the English-likeness
monster". His example is that instead of

x = 4

you have to say

copy 4 to x


The syntax was taken directly from HyperCard.
Jul 18 '05 #63
Anna wrote:
You cut something from that...

"""It's not, after all, the word "lambda" itself; I would still
have some issues with using, say "function", instead of "lambda", but
at least then I would immediately know what I was looking at..."""

I would have fewer ambiguities about using, say "func" rather than
lambda. Lambda always makes me feel like I'm switching to some *other*
language (specifically, Greek - I took a couple of semesters of Attic
Greek in college and quite enjoyed it.) But, the fact that lambda
Good God, you mean there's a language just for the attic? Those Greeks
certainly believed in linguistic specialization, didn't they?
doesn't MEAN anything (and has come - I mean - DELTA at least has a
fairly commonly understood meaning, even at high-school level math.
But, lambda? If it was "func" or "function" or even "def", I would be
happier. At least that way I'd have some idea what it was supposed to
be...
Well, I suspect that Church originally chose lambda precisely because of
its meaninglessness, and I'm always amused when mathematical types try
to attribute an intuitive meaning to the word. It's purely a learned
association, which some arrogantly assume simply *everyone* knows or
should know.

Not that I'm trying to write off lambda supporters as arrogant (though I
*do* have a suspicion that many of them break the wrong end of their
boiled eggs).
BTW - I am *quite* happy with the proposal for "where:" syntax - I
think it handles the problems I have with lambda quite handily.

Whereas I find it to be an excrescence, proving (I suppose) that one
man's meat is another person's poison, or something.

regards
Steve

[who only speaks Ground Floor English]
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
Holden Web LLC +1 703 861 4237 +1 800 494 3119
Jul 18 '05 #64
....

[Anna]
BTW - I am *quite* happy with the proposal for "where:" syntax - I
think it handles the problems I have with lambda quite handily.

[Steve Holden] Whereas I find it to be an excrescence, proving (I suppose) that one
man's meat is another person's poison, or something.


I've been waiting for someone to mention this, but looks like nobody
will, so I'm elected. Modern functional languages generally have two
forms of local-name definition, following common mathematical
conventions. "where" was discussed here. The other is "let/in", and
seems a more natural fit to Python's spelling of block structure:

let:
suite
in:
suite

There's no restriction to expressions here. I suppose that, like the
body of a class, the `let` suite is executed starting with a
conceptually empty local namespace, and whatever the suite binds to a
local name becomes a temporary binding in the `in` suite (like
whatever a class body binds to local names becomes the initial value
of the class __dict__). So, e.g.,

i = i1 = 3
let:
i1 = i+1
from math import sqrt
in:
print i1, sqrt(i1)
print i1,
print sqrt(i1)

would print

4 2
3

and then blow up with a NameError.

LIke it or not, it doesn't seem as strained as trying to pile more
gimmicks on Python expressions.
Jul 18 '05 #65
Steve Holden <st***@holdenweb.com> writes:
Well, I suspect that Church originally chose lambda precisely because
of its meaninglessness,


IAANM, Church didn't choose lambda at all. He chose to put a "hat"
(like a circumflex accent) above the bound name. Then, because of some
typesetting difficulties, this was transformed into the nearest thing
that looked like it: a capital lambda in front of the name ... and
later the capital lambda turned into a lowercase one.
Jul 18 '05 #66
Jeff Shannon <je**@ccvcorp.com> writes:
Jacek Generowicz wrote:
"Anna" <an*******@gmail.com> writes:
But first, wouldn't something like:

[x+1 for x in seq]

be even clearer? I'm glad you mentioned that. [...]

As to whether it is clearer. That depends. I would venture to suggest

that, given a pool of laboratory rats with no previous exposure to
Python, more of them would understand the map-lambda than the list
comprehension.

I would venture to suggest the exact opposite, that the syntax of a
list comprehension is in itself suggestive of its meaning, while 'map'
and 'lambda' are opaque until you've researched them.


In the population of all laboratory rats, I think that the proportion
that would understand either form, would be as good as zero.

Given a population with previous exposure to computer programming, my
money is on the map-lambda version. But this last point is mostly
irrelevant. The fact is that you cannot program computers without
doing a bit of learning ... and the lambda, map and friends really do
not take any significant learning.
Speaking for *this* laboratory rat, at least, map/lambda was always a
nasty puzzle for me and difficult to sort out. But when list comps
were introduced, after reading just a sentence or two on how they
worked, they were completely clear and understandable -- much more so
than map/lambda after many months of exposure.


Forgetting about lambda, map, filter and reduce, do you find that you
pass callables around in your Python programs, or is this not
typically done in your programs?
Jul 18 '05 #67
Jacek:
Given a population with previous exposure to computer programming, my
money is on the map-lambda version. But this last point is mostly
irrelevant. The fact is that you cannot program computers without
doing a bit of learning ... and the lambda, map and friends really do
not take any significant learning.


This kind of "sociological" study would be pretty interesting to me ;-)

Personally, I find out that my mind manage pretty well one-level of
indirection
at time, not two. Consider for instance

def add1(x): return x+1
map(add1, mylist)

Here there are *two* levels of indirection:

first, I need to define add1;
second I need to translate mentally map to a loop.

Using lambda does not help:

map(lambda x: x+1, mylist)

still would require two levels for me, one to recognize the lambda
and one to convert map to a loop.

This is too much for me, so I just write

[x+1 for x in mylist]

where everything is explicit (or if you wish, I have just to recognize
that there
is a loop going on, pretty easy).

However, if I can skip a level of indirection (i.e. I do not need to
define
a function) I just prefer map:

map(int, mylist)

is simpler for me than

[int(x) for x in mylist]

since the latter introduces an useless x (which is also polluting my
namespace,
but this not my point, I could use a generator-expression instead).

So, in practice, I only use map with built-in or with predefined
functions, i.e. functions
which are already there for some other purpose; I do not like to be
forced to write a
function (or a lambda) for the only purpose of using map (at least in
Python).

Incidentally, I am not fond of the name "lambda" too. "fn", as Paul
Graham says,
looks much better.

What I would like, in Python, is some facility to manage callbacks in
the standard
library, then I would live pretty well without lambdas.
Just IMHO, YMMV, etc.

Michele Simionato

Jul 18 '05 #68
On Mon, 10 Jan 2005 21:15:50 -0500, Tim Peters <ti********@gmail.com> wrote:
...

[Anna]
BTW - I am *quite* happy with the proposal for "where:" syntax - I
think it handles the problems I have with lambda quite handily.

[Steve Holden]
Whereas I find it to be an excrescence, proving (I suppose) that one
man's meat is another person's poison, or something.


I've been waiting for someone to mention this, but looks like nobody
will, so I'm elected. Modern functional languages generally have two
forms of local-name definition, following common mathematical
conventions. "where" was discussed here. The other is "let/in", and

Well, I did say it reminded me of some kind of weird let ;-)
http://groups-beta.google.com/groups...r=&sa=N&tab=wg
seems a more natural fit to Python's spelling of block structure:

let:
suite
in:
suite

There's no restriction to expressions here. I suppose that, like the
body of a class, the `let` suite is executed starting with a
conceptually empty local namespace, and whatever the suite binds to a
local name becomes a temporary binding in the `in` suite (like
whatever a class body binds to local names becomes the initial value
of the class __dict__). So, e.g.,

i = i1 = 3
let:
i1 = i+1
from math import sqrt
in:
print i1, sqrt(i1)
print i1,
print sqrt(i1)

would print

4 2
3

and then blow up with a NameError.

LIke it or not, it doesn't seem as strained as trying to pile more
gimmicks on Python expressions.

I could get to like it ;-)

Hm, a little extension to this could provide a new way to populate closure variables,
and also (never mind, one thing at a time ;-)

#1: If you gave your 'let' above a list of 'externs' that can be rebound from within the let.
E.g.,

let(sqrt):

the effect in your example would be to eliminate the NameError you mention.
The compiler would make an entry for sqrt in the enclosing namespace, and generate
code to bind/rebind if assigned from within the let.

This would be an interesting way to create closure bindings:

let(foo):
preset = 'another way to make closure vairables'
in:
def foo(): return preset
...
print foo()

#2: Making the in: suite callable as a light weight function with no arguments. An optional
binding name after in would bind like def and create a persistent named callable instead of just an
implicitly called anonymous suite.

Then you could define the same effective foo by

let:
preset = 'another way to make closure vairables'
in foo:
return preset # return now legal
...
print foo()

The combination would work like:

let(rebindable):
factor = 10
in bar:
rebindable *= factor

rebindable = 2
bar()
print rebindable # => 20
rebindable += 5
bar()
print rebindable # => 250

You can see this could be used nicely in case functionality, with a dict of named in-functions.

What do you think?

Regards,
Bengt Richter
Jul 18 '05 #69
Tim Peters wrote:
LIke it or not, it doesn't seem as strained as trying to pile more
gimmicks on Python expressions.


Some of us are piling gimmicks on statements, not expressions :)

And I'm looking for out-of-order code execution as well as local namespaces, so
the let/in syntax wouldn't help much. (The out-of-order execution is what really
makes the property definition example pretty, IMO)

Cheers,
Nick.

--
Nick Coghlan | nc******@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
Jul 18 '05 #70
Tim Peters wrote:
...

[Anna]
BTW - I am *quite* happy with the proposal for "where:" syntax - I
think it handles the problems I have with lambda quite handily.
[Steve Holden]
Whereas I find it to be an excrescence, proving (I suppose) that
one man's meat is another person's poison, or something.


I've been waiting for someone to mention this, but looks like nobody
will, so I'm elected. Modern functional languages generally have two
forms of local-name definition, following common mathematical
conventions. "where" was discussed here. The other is "let/in", and
seems a more natural fit to Python's spelling of block structure:

let:
suite
in:
suite


Ah. During that discussion, I did kind of suggest this (spelling it
where...do) as an alternative to where (thinking I was clever). Only
no one seemed to take notice, probably because I suggested something
more poignant at the same time.

Now I see why I liked the idea so much; it was exactly like let forms.

There's no restriction to expressions here. I suppose that, like the
body of a class, the `let` suite is executed starting with a
conceptually empty local namespace, and whatever the suite binds to a
local name becomes a temporary binding in the `in` suite (like
whatever a class body binds to local names becomes the initial value
of the class __dict__). So, e.g.,

i = i1 = 3
let:
i1 = i+1
from math import sqrt
in:
print i1, sqrt(i1)
print i1,
print sqrt(i1)

would print

4 2
3

and then blow up with a NameError.

LIke it or not, it doesn't seem as strained as trying to pile more
gimmicks on Python expressions.


Indeed.
--
CARL BANKS

Jul 18 '05 #71
Jacek Generowicz wrote:
Given a population with previous exposure to computer programming, my
money is on the map-lambda version. But this last point is mostly
irrelevant. The fact is that you cannot program computers without
doing a bit of learning ... and the lambda, map and friends really do
not take any significant learning.


I guess we'll have to agree to disagree, because given the same
conditions, I *still* think that a list comprehension expresses its
semantics more clearly than map/lambda. I'd also point out that not
all Python programmers will have significant prior exposure to
programming ideas, and even those who do will not necessarily have
prior exposure to lambdas.

It's true that programming requires learning, and that map/lambda
aren't a tremendous burden to learn. Still, to my mind they make a
program a tiny increment more complicated. (I find that reading a
lambda requires mentally pushing a stack frame to parse the lambda and
another to translate map() into a loop, whereas a list comp's
expression doesn't require such a shift, and a function name works as
a good placeholder that makes reading easier.) It's not a big
difference in any individual case, but incremental differences build up.

From the sounds of it, you may have the opposite experience with
reading map/lambda vs. reading list comps, though, so we could go back
and forth on this all week without convincing the other. :)
Speaking for *this* laboratory rat, at least, map/lambda was always a
nasty puzzle for me and difficult to sort out. But when list comps
were introduced, after reading just a sentence or two on how they
worked, they were completely clear and understandable -- much more so
than map/lambda after many months of exposure.


Forgetting about lambda, map, filter and reduce, do you find that you
pass callables around in your Python programs, or is this not
typically done in your programs?


Sure, I pass callables around quite a bit. Usually they're GUI
callbacks or the like. Usually they're also either complex enough
that lambda would be undesireable if not impossible, or they're simple
and numerous (e.g. calling a function with different parameters) such
that it's easy to write a factory function that returns closures
rather than feed the parameter in with a lambda.

Jeff Shannon
Technician/Programmer
Credit International

Jul 18 '05 #72
In article <10*************@corp.supernews.com>,
Jeff Shannon <je**@ccvcorp.com> wrote:
....
From the sounds of it, you may have the opposite experience with
reading map/lambda vs. reading list comps, though, so we could go back
and forth on this all week without convincing the other. :)


I'm with him. List incomprehensions do not parse well in
my eyes. I am reduced to guessing what they mean by a kind
of process of elimination. map is simply a function, so
it doesn't pose any extra reading problem, and while lambda
is awkward it isn't syntactically all that novel.

Donn Cave, do**@u.washington.edu
Jul 18 '05 #73
Donn Cave <do**@u.washington.edu> writes:
List incomprehensions do not parse well in my eyes.


Are you familiar with the Haskell syntax for list comprehensions?

For example:

http://www.zvon.org/other/haskell/Ou...reference.html

Does their striking similarity to mathematical set notation help at
all ?
Jul 18 '05 #74
Jeff Shannon <je**@ccvcorp.com> writes:
I guess we'll have to agree to disagree
Indeed :-)
I find that reading a lambda requires mentally pushing a stack frame
to parse the lambda and another to translate map() into a loop,
whereas a list comp's expression doesn't require such a shift From the sounds of it, you may have the opposite experience with
reading map/lambda vs. reading list comps


No, I'm perefectly happy with both. I'm just trying to understand the
underlying reasons for people having trouble with one or the other, in
order to be better armed when the didactic need might arise.

One more question. Imagine that Python had something akin to Smalltalk
code blocks. Would something like

map([x | x+1], seq)

be any better for you than

map(lambda x:x+1, seq)

?
Jul 18 '05 #75
In article <ty*************@pcepsft001.cern.ch>,
Jacek Generowicz <ja**************@cern.ch> wrote:
Donn Cave <do**@u.washington.edu> writes:
List incomprehensions do not parse well in my eyes.
Are you familiar with the Haskell syntax for list comprehensions?

For example:

http://www.zvon.org/other/haskell/Ou...on_reference.h


I haven't used it more than once or twice in the modest
amount of Haskell code I've written, but I've seen it
a few times.
Does their striking similarity to mathematical set notation help at
all ?


Not a bit.

If it's any more obvious than the Python version, I suppose
it's the | -- my parser sees [a|b] on the first pass.

But it isn't like I ever made any real effort to get comfortable
with Python list comprehensions. I was just relaying my (lack of)
intuitive grasp of them, compared to map and lambda.

Donn Cave, do**@u.washington.edu
Jul 18 '05 #76
Jacek Generowicz wrote:
One more question. Imagine that Python had something akin to Smalltalk
code blocks. Would something like

map([x | x+1], seq)

be any better for you than

map(lambda x:x+1, seq)

?


I'd say that this is very slightly better, but it's much closer (in my
mind) to map/lambda than it is to a list comprehension. In this case,
at least the code block is visually self-contained in a way that
lambdas are not, but I still have to do more mental work to visualize
the overall results than I need with list comps.

Jeff Shannon
Technician/Programmer
Credit International

Jul 18 '05 #77

This discussion thread is closed

Replies have been disabled for this discussion.

By using this site, you agree to our Privacy Policy and Terms of Use.