Re: Securing a future for anonymous functions in Python

2005-01-12 Thread Jacek Generowicz
Jeff Shannon [EMAIL PROTECTED] 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

Re: Securing a future for anonymous functions in Python

2005-01-12 Thread Jacek Generowicz
Donn Cave [EMAIL PROTECTED] 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/Outputsyntax/listQcomprehension_reference.html Does their striking similarity to

Re: Securing a future for anonymous functions in Python

2005-01-12 Thread Donn Cave
In article [EMAIL PROTECTED], Jacek Generowicz [EMAIL PROTECTED] wrote: Donn Cave [EMAIL PROTECTED] writes: List incomprehensions do not parse well in my eyes. Are you familiar with the Haskell syntax for list comprehensions? For example:

Re: Securing a future for anonymous functions in Python

2005-01-12 Thread Jeff Shannon
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

Re: Securing a future for anonymous functions in Python

2005-01-11 Thread Jacek Generowicz
Jeff Shannon [EMAIL PROTECTED] writes: Jacek Generowicz wrote: Anna [EMAIL PROTECTED] 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

Re: Securing a future for anonymous functions in Python

2005-01-11 Thread michele . simionato
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

Re: Securing a future for anonymous functions in Python

2005-01-11 Thread Bengt Richter
On Mon, 10 Jan 2005 21:15:50 -0500, Tim Peters [EMAIL PROTECTED] 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

Re: Securing a future for anonymous functions in Python

2005-01-11 Thread Nick Coghlan
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

Re: Securing a future for anonymous functions in Python

2005-01-11 Thread Carl Banks
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

Re: Securing a future for anonymous functions in Python

2005-01-11 Thread Jeff Shannon
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

Re: Securing a future for anonymous functions in Python

2005-01-11 Thread Donn Cave
In article [EMAIL PROTECTED], Jeff Shannon [EMAIL PROTECTED] 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

Re: Securing a future for anonymous functions in Python

2005-01-10 Thread Tim Peters
... [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

Re: Securing a future for anonymous functions in Python

2005-01-10 Thread Jacek Generowicz
Nick Coghlan [EMAIL PROTECTED] writes: 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, And I suspect that

Re: Securing a future for anonymous functions in Python

2005-01-10 Thread Anna
Jacek Generowicz wrote: Anna [EMAIL PROTECTED] writes: With class and def, I at least have a *name* to start with - class Square pretty obviously is going to have something to do with geometric shapes, I would hope (or maybe with boring people...). Or maybe with multiplying something by

Re: Securing a future for anonymous functions in Python

2005-01-10 Thread Ville Vainio
James == James Stroud [EMAIL PROTECTED] writes: James I think we should not try too hard to make everything James English like. Its a crappy language anyway (though its James the only one I speak good). Matt Neuberg, QOTW material, unless you stole this from someone else :-). --

Re: Securing a future for anonymous functions in Python

2005-01-10 Thread Jacek Generowicz
Anna [EMAIL PROTECTED] writes: Jacek Generowicz wrote: Anna [EMAIL PROTECTED] writes: With class and def, I at least have a *name* to start with - class Square pretty obviously is going to have something to do with geometric shapes, I would hope (or maybe with boring people...).

Re: Securing a future for anonymous functions in Python

2005-01-10 Thread Jeff Shannon
Jacek Generowicz wrote: Anna [EMAIL PROTECTED] 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

Re: Securing a future for anonymous functions in Python

2005-01-10 Thread Anna
Same here. -- http://mail.python.org/mailman/listinfo/python-list

Re: Securing a future for anonymous functions in Python

2005-01-07 Thread Alan Gauld
On Thu, 06 Jan 2005 21:02:46 -0600, Doug Holton [EMAIL PROTECTED] wrote: 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

Re: Securing a future for anonymous functions in Python

2005-01-07 Thread 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. Alan Gauld wrote: On Thu, 30 Dec 2004 23:28:46 +1000, Nick Coghlan [EMAIL PROTECTED] wrote: GvR has commented that he want to

Re: Securing a future for anonymous functions in Python

2005-01-07 Thread Paul Rubin
Anna [EMAIL PROTECTED] writes: 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

Re: Securing a future for anonymous functions in Python

2005-01-07 Thread Steve Holden
Paul Rubin wrote: Anna [EMAIL PROTECTED] writes: 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

Re: Securing a future for anonymous functions in Python

2005-01-07 Thread Paul Rubin
Steve Holden [EMAIL PROTECTED] writes: 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. -- http://mail.python.org/mailman/listinfo/python-list

Re: Securing a future for anonymous functions in Python

2005-01-07 Thread Jacek Generowicz
Anna [EMAIL PROTECTED] writes: 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

Re: Securing a future for anonymous functions in Python

2005-01-07 Thread Steven Bethard
Alan Gauld wrote: On Thu, 06 Jan 2005 21:02:46 -0600, Doug Holton [EMAIL PROTECTED] wrote: 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

Re: Securing a future for anonymous functions in Python

2005-01-07 Thread Nick Coghlan
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,

Re: Securing a future for anonymous functions in Python

2005-01-07 Thread Nick Coghlan
Paul Rubin wrote: Anna [EMAIL PROTECTED] writes: 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

Re: Securing a future for anonymous functions in Python

2005-01-07 Thread Jacek Generowicz
Nick Coghlan [EMAIL PROTECTED] 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

Re: Securing a future for anonymous functions in Python

2005-01-07 Thread Nick Coghlan
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

Re: Securing a future for anonymous functions in Python

2005-01-07 Thread Donn Cave
In article [EMAIL PROTECTED], Jeff Shannon [EMAIL PROTECTED] 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.

Re: Securing a future for anonymous functions in Python

2005-01-07 Thread Paul Rubin
Nick Coghlan [EMAIL PROTECTED] 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

Re: Securing a future for anonymous functions in Python

2005-01-07 Thread Bengt Richter
On 07 Jan 2005 14:38:01 +0100, Jacek Generowicz [EMAIL PROTECTED] 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

Re: Securing a future for anonymous functions in Python

2005-01-07 Thread Bengt Richter
On 07 Jan 2005 13:24:39 -0800, Paul Rubin http://[EMAIL PROTECTED] wrote: Nick Coghlan [EMAIL PROTECTED] 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

Re: Securing a future for anonymous functions in Python

2005-01-07 Thread Jeff Shannon
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

Re: Securing a future for anonymous functions in Python

2005-01-07 Thread Terry Hancock
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

Re: Securing a future for anonymous functions in Python

2005-01-07 Thread Steven Bethard
Alan Gauld wrote: On Fri, 07 Jan 2005 08:44:57 -0700, Steven Bethard [EMAIL PROTECTED] 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,

Re: Securing a future for anonymous functions in Python

2005-01-07 Thread BJörn 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

Re: Securing a future for anonymous functions in Python

2005-01-07 Thread James Stroud
On Friday 07 January 2005 01:24 pm, Paul Rubin wrote: Nick Coghlan [EMAIL PROTECTED] 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

Re: Securing a future for anonymous functions in Python

2005-01-07 Thread Roy Smith
In article [EMAIL PROTECTED], James Stroud [EMAIL PROTECTED] wrote: On Friday 07 January 2005 01:24 pm, Paul Rubin wrote: Nick Coghlan [EMAIL PROTECTED] writes: Add in the fact that there are many, many Python programmers with non-CS backgrounds, and the term 'lambda' sticks out like a

Re: Securing a future for anonymous functions in Python

2005-01-06 Thread Nick Coghlan
Paul Rubin wrote: Nick Coghlan [EMAIL PROTECTED] writes: Do you consider generator expressions or list comprehensions deficient because they don't allow several statements in the body of the for loop? I don't see what it would mean to do otherwise. Exactly the same as a suite would in the

Re: Securing a future for anonymous functions in Python

2005-01-06 Thread Jeff Shannon
Alan Gauld wrote: 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

Re: Securing a future for anonymous functions in Python

2005-01-06 Thread Paul Rubin
Jeff Shannon [EMAIL PROTECTED] writes: It seems to me that in other, less-dynamic languages, lambdas are significantly different from functions in that lambdas can be created at runtime. What languages are those, where you can create anonymous functions at runtime, but not named functions?!

Re: Securing a future for anonymous functions in Python

2005-01-06 Thread Terry Reedy
Alan Gauld [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Thu, 30 Dec 2004 23:28:46 +1000, Nick Coghlan [EMAIL PROTECTED] wrote: 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, Can I ask what

Re: Securing a future for anonymous functions in Python

2005-01-05 Thread Paul Rubin
Nick Coghlan [EMAIL PROTECTED] writes: Do you consider generator expressions or list comprehensions deficient because they don't allow several statements in the body of the for loop? I don't see what it would mean to do otherwise. -- http://mail.python.org/mailman/listinfo/python-list

Re: Securing a future for anonymous functions in Python

2005-01-01 Thread Simo Melenius
Doug Holton [EMAIL PROTECTED] writes: Steven Bethard wrote: Simo Melenius wrote: map (def x: Oops, I found a typo alreay. I meant to write def (x): -- no name for anonymous functions but just the argument list, please :) Right the comma plus other things make this difficult for a parser

Re: Securing a future for anonymous functions in Python

2004-12-31 Thread Ian Bicking
John Roth wrote: I appreciate some of the motivation, but merely avoiding giving something a name doesn't seem like a laudible goal. Actually, it is a laudable goal. It's always easier to understand something when it's right in front of your face than if it's off somewhere else. Naming the

Re: Securing a future for anonymous functions in Python

2004-12-31 Thread Steven Bethard
Alex Martelli wrote: Paul L. Du Bois [EMAIL PROTECTED] wrote: def fn(gen): Turns a generator expression into a callable. def anonymous(*args): return gen.next() return anonymous def args(): Works with fn(); yields args passed to anonymous(). while True: yield

Re: Securing a future for anonymous functions in Python

2004-12-31 Thread Scott David Daniels
David Bolen wrote: So for example, an asynchronous sequence of operations might be like: d = some_deferred_function() d.addCallback(lambda x: next_function()) d.addCallback(lambda blah: third_function(otherargs, blah)) d.addCallback(lambda x: last_function()) which to me is more

Re: Securing a future for anonymous functions in Python

2004-12-31 Thread Alex Martelli
Steven Bethard [EMAIL PROTECTED] wrote: Does that seem about right? Yep! P.S. That's so *evilly* cool! We should have an Evilly Cool Hack of the Year, and I nominate Paul du Bois's one as the winner for 2004. Do I hear any second...? Alex --

Re: Securing a future for anonymous functions in Python

2004-12-31 Thread Paul Rubin
[EMAIL PROTECTED] (Alex Martelli) writes: We should have an Evilly Cool Hack of the Year, and I nominate Paul du Bois's one as the winner for 2004. Do I hear any second...? The year's not over yet :). -- http://mail.python.org/mailman/listinfo/python-list

Re: Securing a future for anonymous functions in Python

2004-12-31 Thread Ian Bicking
David Bolen wrote: Ian Bicking [EMAIL PROTECTED] writes: The one motivation I can see for function expressions is callback-oriented programming, like: get_web_page(url, when_retrieved={page | give_page_to_other_object(munge_page(page))}) This is my primary use case for lambda's

Re: Securing a future for anonymous functions in Python

2004-12-31 Thread David Bolen
Scott David Daniels [EMAIL PROTECTED] writes: David Bolen wrote: So for example, an asynchronous sequence of operations might be like: d = some_deferred_function() d.addCallback(lambda x: next_function()) d.addCallback(lambda blah: third_function(otherargs, blah))

Re: Securing a future for anonymous functions in Python

2004-12-31 Thread Scott David Daniels
David Bolen wrote: Scott David Daniels [EMAIL PROTECTED] writes: while test() != False: ...code... I'm not sure I follow the error in this snippet... The code is fat -- clearer is: while test(): ...code... The right sequence using lambda is: d =

Of closures and expressing anonymous functions [Was: Re: Securing a future for anonymous functions in Python]

2004-12-31 Thread Simo Melenius
[EMAIL PROTECTED] (Bengt Richter) writes: Closure is the name for the whole thing, apparently, not just the environment the procedure body needs, which was the aspect that I (mis)attached the name to. Which brings me to the point where I'd welcome more flexibility in writing to variables

Re: Securing a future for anonymous functions in Python

2004-12-31 Thread Simo Melenius
Ian Bicking [EMAIL PROTECTED] writes: But I do think there's other ways to approach this. Function expressions could get really out of hand, IMHO, and could easily lead to twenty-line expressions. That's aesthetically incompatible with Python source, IMHO. You can already write unaesthetic

Re: Securing a future for anonymous functions in Python

2004-12-31 Thread Steven Bethard
Simo Melenius wrote: map (def x: if foo (x): return baz_1 (x) elif bar (x): return baz_2 (x) else: global hab hab.append (x) return baz_3 (hab), [1,2,3,4,5,6]) I think this would probably have to be

Re: Securing a future for anonymous functions in Python

2004-12-31 Thread Simo Melenius
Steven Bethard [EMAIL PROTECTED] writes: Simo Melenius wrote: map (def x: if foo (x): return baz_1 (x) elif bar (x): return baz_2 (x) else: global hab hab.append (x) return baz_3 (hab),

Re: Securing a future for anonymous functions in Python

2004-12-31 Thread Doug Holton
Steven Bethard wrote: Simo Melenius wrote: map (def x: if foo (x): return baz_1 (x) elif bar (x): return baz_2 (x) else: global hab hab.append (x) return baz_3 (hab), [1,2,3,4,5,6]) I think this would

Re: Of closures and expressing anonymous functions [Was: Re: Securing a future for anonymous functions in Python]

2004-12-31 Thread Terry Reedy
Simo Melenius [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [EMAIL PROTECTED] (Bengt Richter) writes: Which brings me to the point where I'd welcome more flexibility in writing to variables outside the local scope. This idea was discussed extensively on PyDev perhaps 2 years ago.

Securing a future for anonymous functions in Python

2004-12-30 Thread Nick Coghlan
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

Re: Securing a future for anonymous functions in Python

2004-12-30 Thread Nick Coghlan
Paul Rubin wrote: Nick Coghlan [EMAIL PROTECTED] writes: Anyway, I'm looking for feedback on a def-based syntax that came up in a recent c.l.p discussion: Looks like just an even more contorted version of lambda. It doesn't fix lambda's main deficiency which is inability to have several

Re: Securing a future for anonymous functions in Python

2004-12-30 Thread Jp Calderone
On Fri, 31 Dec 2004 00:00:31 +1000, Nick Coghlan [EMAIL PROTECTED] wrote: Paul Rubin wrote: Nick Coghlan [EMAIL PROTECTED] writes: Anyway, I'm looking for feedback on a def-based syntax that came up in a recent c.l.p discussion: Looks like just an even more contorted version of

Re: Securing a future for anonymous functions in Python

2004-12-30 Thread Nick Coghlan
Jp Calderone wrote: On Fri, 31 Dec 2004 00:00:31 +1000, Nick Coghlan [EMAIL PROTECTED] wrote: Paul Rubin wrote: Nick Coghlan [EMAIL PROTECTED] writes: Anyway, I'm looking for feedback on a def-based syntax that came up in a recent c.l.p discussion: Looks like just an even more contorted version

Re: Securing a future for anonymous functions in Python

2004-12-30 Thread Jp Calderone
On Fri, 31 Dec 2004 00:19:29 +1000, Nick Coghlan [EMAIL PROTECTED] wrote: Jp Calderone wrote: On Fri, 31 Dec 2004 00:00:31 +1000, Nick Coghlan [EMAIL PROTECTED] wrote: Paul Rubin wrote: Nick Coghlan [EMAIL PROTECTED] writes: Anyway, I'm looking for feedback on a def-based syntax that

RE: Securing a future for anonymous functions in Python

2004-12-30 Thread Batista, Facundo
Title: RE: Securing a future for anonymous functions in Python [Nick Coghlan] #- I just don't understand why people complain so much about #- the restriction to a #- single _expression_ in lambdas, yet there is nary a peep about #- the same #- restriction for generator expressions and

Re: Securing a future for anonymous functions in Python

2004-12-30 Thread Michael Spencer
Nick Coghlan wrote: 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,

Re: Securing a future for anonymous functions in Python

2004-12-30 Thread Ian Bicking
John Roth wrote: The syntax I prefer (and I don't know if it's actually been suggested before) is to use braces, that is { and }. In other words, an anonymous function looks like: {p1, p2, p3 | stmt1 stmt2 } What's the advantage of something like that over the non-anonymous

Re: Securing a future for anonymous functions in Python

2004-12-30 Thread Roy Smith
Ian Bicking [EMAIL PROTECTED] wrote: I think this specific use case -- defining callbacks -- should be addressed, rather than proposing a solution to something that isn't necessary. Which is to say, no one *needs* anonymous functions; people may need things which anonymous functions

Re: Securing a future for anonymous functions in Python

2004-12-30 Thread Skip Montanaro
John In other words, an anonymous function looks like: John {p1, p2, p3 | John stmt1 John stmt2 John } John There are two reasons for using braces. One is that it's the John common syntax for blocks in a large number of languages. Yeah, but it's

Re: Securing a future for anonymous functions in Python

2004-12-30 Thread Carl Banks
Nick Coghlan wrote: 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. I shall

Re: Securing a future for anonymous functions in Python

2004-12-30 Thread David Bolen
Ian Bicking [EMAIL PROTECTED] writes: The one motivation I can see for function expressions is callback-oriented programming, like: get_web_page(url, when_retrieved={page | give_page_to_other_object(munge_page(page))}) This is my primary use case for lambda's nowadays as

Re: Securing a future for anonymous functions in Python

2004-12-30 Thread Paul L. Du Bois
Jp Calderone wrote: I'm not saying boo hoo lambdas are crippled fix them waah. I'm saying Lambdas and generator comprehensions are not comparable in this sense and arguments based on one should not be used to support positions about the other. This post and Michael Spencer's post which

Re: Securing a future for anonymous functions in Python

2004-12-30 Thread Bengt Richter
On Thu, 30 Dec 2004 23:28:46 +1000, Nick Coghlan [EMAIL PROTECTED] wrote: 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

Re: Securing a future for anonymous functions in Python

2004-12-30 Thread John Roth
Ian Bicking [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] John Roth wrote: The syntax I prefer (and I don't know if it's actually been suggested before) is to use braces, that is { and }. In other words, an anonymous function looks like: {p1, p2, p3 | stmt1 stmt2 }

Re: Securing a future for anonymous functions in Python

2004-12-30 Thread Jeff Shannon
David Bolen wrote: I think this specific use case -- defining callbacks -- should be addressed, rather than proposing a solution to something that isn't necessary. (...) I'd be interested in this approach too, especially if it made it simpler to handle simple manipulation of callback

Re: Securing a future for anonymous functions in Python

2004-12-30 Thread Bengt Richter
On Thu, 30 Dec 2004 15:15:51 -0800, Jeff Shannon [EMAIL PROTECTED] wrote: David Bolen wrote: I think this specific use case -- defining callbacks -- should be addressed, rather than proposing a solution to something that isn't necessary. (...) I'd be interested in this approach too,

Re: Securing a future for anonymous functions in Python

2004-12-30 Thread Jeff Shannon
Bengt Richter wrote: On Thu, 30 Dec 2004 15:15:51 -0800, Jeff Shannon [EMAIL PROTECTED] wrote: Mimicking function-def indentation inside of another function's arglist strikes me as an abomination just waiting to happen; in comparison, the need to type a name twice seems trivial. Self-restraint

Re: Securing a future for anonymous functions in Python

2004-12-30 Thread Nick Coghlan
Batista, Facundo wrote: [Nick Coghlan] #- I just don't understand why people complain so much about #- the restriction to a #- single expression in lambdas, yet there is nary a peep about #- the same #- restriction for generator expressions and list comprehensions. What *I* don't understand (and

Re: Securing a future for anonymous functions in Python

2004-12-30 Thread Nick Coghlan
Bengt Richter wrote: This is an easy trap to fall into, so if the new lambda-substitute could provide a prettier current-closure-variable-value capture than passing a dummy default value or nesting another def and passing the value in, to provide a private closure for each, that might be

Re: Securing a future for anonymous functions in Python

2004-12-30 Thread Nick Coghlan
Carl Banks wrote: Nick Coghlan wrote: In much the same way that programmers often spend a lot of time optimizing parts of their program that will yield very minor dividends, while they could have spent that time working on other things that will pay off a lot, many of the wannabe language

Re: Securing a future for anonymous functions in Python

2004-12-30 Thread Nick Coghlan
Michael Spencer wrote: while we're at it, perhaps 'for' would be more appropriate: (expression for args(a, *args, **kw)) Hmm, what about an 'abbreviated generator expression' syntax: (expression for args-tuple) For instance: (f(a) + g(b) - h(c) for (a, b, c)) (the 'in' clause of the standard

Re: Securing a future for anonymous functions in Python

2004-12-30 Thread Bengt Richter
On Thu, 30 Dec 2004 17:39:06 -0800, Jeff Shannon [EMAIL PROTECTED] wrote: Bengt Richter wrote: On Thu, 30 Dec 2004 15:15:51 -0800, Jeff Shannon [EMAIL PROTECTED] wrote: Mimicking function-def indentation inside of another function's arglist strikes me as an abomination just waiting to

Re: Securing a future for anonymous functions in Python

2004-12-30 Thread Steven Bethard
Jeff Shannon wrote: My thesis here is that one of the most common (legitimate) uses of lambda is as an adapter, to create an intermediary that allows a callable with a given signature to be used in places where a different signature is expected -- that is, altering the number or order of

Re: Securing a future for anonymous functions in Python

2004-12-30 Thread Paul Rubin
[EMAIL PROTECTED] (Bengt Richter) writes: print either(A == B, (def A equals B), (def A does not equal B)) either(thefile, (def thefile.close()), (def 0)) I'd really rather have some reasonable macro facility, than to resort to using anonymous functions and deferred evaluation for common things