Re: Creating lambdas inside generator expression

On 29/06/2022 23:17, Chris Angelico wrote: On Thu, 30 Jun 2022 at 02:49, Johannes Bauer wrote: But now consider what happens when we create the lambdas inside a list comprehension (in my original I used a generator expresison, but the result is the same). Can you guess what happens when we

Re: Creating lambdas inside generator expression

On Thu, 30 Jun 2022 at 02:49, Johannes Bauer wrote: > But now consider what happens when we create the lambdas inside a list > comprehension (in my original I used a generator expresison, but the > result is the same). Can you guess what happens when we create conds > like thi

Re: Creating lambdas inside generator expression

sg: msg.hascode("foo"), lambda msg: msg.hascode("bar"), ] msg = Msg() print(conds[0](msg)) print(conds[1](msg)) It works perfectly and does exactly what it looks like. The output is: Check for foo False Check for bar False But now consider what happens when we create the l

Creating lambdas inside generator expression

The output is: Check for foo False Check for bar False But now consider what happens when we create the lambdas inside a list comprehension (in my original I used a generator expresison, but the result is the same). Can you guess what happens when we create conds like this? conds = [ lambda msg: m

Re: Creating lambdas inside generator expression

sg)) > print(conds[1](msg)) > > > > It works perfectly and does exactly what it looks like. The output is: > > Check for foo > False > Check for bar > False > > But now consider what happens when we create the lambdas inside a list > comprehension (in m

Re: Fear and suspicion of lambdas, was Re: Meta decorator with parameters, defined in explicit functions

dieter writes: > Ben Finney writes: > > ... Rather, the motivation was that a complex thing, with many > > moving parts, has an unexplained implementation: a nested set of > > functions without names to explain their part in the pattern. > > In a previous reply, I have tried to explain (apparent

Re: Fear and suspicion of lambdas, was Re: Meta decorator with parameters, defined in explicit functions

Ben Finney writes: > ... > Rather, the motivation was that a complex thing, with many moving parts, > has an unexplained implementation: a nested set of functions without > names to explain their part in the pattern. In a previous reply, I have tried to explain (apparently without success) that t

Re: Fear and suspicion of lambdas, was Re: Meta decorator with parameters, defined in explicit functions

Ben Bacarisse writes: > By replying I'm not accepting the premise -- I have no idea if there > is widespread fear and suspicion of lambdas among Python users but it > seems unlikely. I can testify, as the person who started this thread, that there is no fear or suspicion of lamb

Re: Fear and suspicion of lambdas, was Re: Meta decorator with parameters, defined in explicit functions

dieter writes: >> Lawrence D’Oliveiro wrote: >>> I don’t know why this fear and suspicion of lambdas is so widespread among >>> Python users ... former Java/C# programmers, perhaps? By replying I'm not accepting the premise -- I have no idea if there is widespread

Re: Fear and suspicion of lambdas, was Re: Meta decorator with parameters, defined in explicit functions

easily understood. >> >> I don’t know why this fear and suspicion of lambdas is so widespread among >> Python users ... former Java/C# programmers, perhaps? Maybe, it's the name ("lambda"). In Javascript, anonymous functions are widespread (and extensively used fo

Re: Fear and suspicion of lambdas, was Re: Meta decorator with parameters, defined in explicit functions

ce side effects that it improves the readability of tracebacks >> and allows you to provide a docstring. > > True, but then again the original had three lambdas, so one line would > have to become at least 3×2 = 6 lines, more if you want docstrings. > >> def reduce(items, fun

Re: Fear and suspicion of lambdas, was Re: Meta decorator with parameters, defined in explicit functions

t;> >> with the nice side effects that it improves the readability of tracebacks >> and allows you to provide a docstring. > > True, but then again the original had three lambdas, so one line would have > to become at least 3×2 = 6 lines, more if you want docstrings. I hear

Re: Fear and suspicion of lambdas, was Re: Meta decorator with parameters, defined in explicit functions

and allows you to provide a docstring. True, but then again the original had three lambdas, so one line would have to become at least 3×2 = 6 lines, more if you want docstrings. > def reduce(items, func=lambda x, y: x + y): ... There was a reason why “reduce” was removed from being a built

Fear and suspicion of lambdas, was Re: Meta decorator with parameters, defined in explicit functions

Lawrence D’Oliveiro wrote: > On Tuesday, June 28, 2016 at 5:03:08 PM UTC+12, Ben Finney wrote: > >> I would like to see a more Pythonic, more explicit and expressive >> replacement with its component parts easily understood. > > I don’t know why this fear and su

Re: Alternative to multi-line lambdas: Assign-anywhere def statements

On Wed, Feb 11, 2015 at 8:56 PM, Chris Angelico wrote: > On Thu, Feb 12, 2015 at 1:57 PM, Ian Kelly wrote: >> The reason I don't like this replacing def isn't because the name is >> necessarily lost. It's because the lack of the well-defined def >> statement encourages more complex usages like >>

Re: Alternative to multi-line lambdas: Assign-anywhere def statements

On Thu, Feb 12, 2015 at 1:57 PM, Ian Kelly wrote: > The reason I don't like this replacing def isn't because the name is > necessarily lost. It's because the lack of the well-defined def > statement encourages more complex usages like > > functions['f'] = x -> x**2 > > where such implicit tran

Re: Alternative to multi-line lambdas: Assign-anywhere def statements

On Wed, Feb 11, 2015 at 7:06 PM, Terry Reedy wrote: >> I can't see why the parser would understand more easily >> >> def f(x): >> return x**2 >> than >> >> f = x-> >> return x**2 > > > The parser parses both equally well. That is not the issue. The compiler could at some point recogniz

Re: Alternative to multi-line lambdas: Assign-anywhere def statements

On 2/11/2015 8:04 AM, Albert van der Horst wrote: It is not until we assign the object to a name (which becomes thereby a function) that the __name__ thingy comes into play, like so. But __name__ would not come into play. f = x->x**2 This would mean to create an anonymous function object

Re: Alternative to multi-line lambdas: Assign-anywhere def statements

On 02/11/2015 05:04 AM, Albert van der Horst wrote: > That's the reason why my ideal Python doesn't attach a name to a lambda > denotation: > > x -> x**2 Hmmm. So now let's say you have a few dozen of these types of functions, and you want to talk about the twenty-sixth one with a peer... are

Re: Alternative to multi-line lambdas: Assign-anywhere def statements

On Wednesday, February 11, 2015 at 8:04:33 AM UTC-5, Albert van der Horst wrote: > In article , > Ethan Furman wrote: > >-=-=-=-=-=- > > > >On 01/24/2015 11:55 AM, Chris Angelico wrote: > >> On Sun, Jan 25, 2015 at 5:56 AM, Ethan Furman wrote: > >>> If the non-generic is what you're concerned ab

Re: Alternative to multi-line lambdas: Assign-anywhere def statements

In article , Ethan Furman wrote: >-=-=-=-=-=- > >On 01/24/2015 11:55 AM, Chris Angelico wrote: >> On Sun, Jan 25, 2015 at 5:56 AM, Ethan Furman wrote: >>> If the non-generic is what you're concerned about: >>> >>> # not tested >>> dispatch_table_a = {} >>> dispatch_table_b = {} >>> dispatch_tabl

Re: Alternative to multi-line lambdas: Assign-anywhere def statements

to the application developer and show the full traceback. Even without source, tracebacks show the names of functions, and lambdas all share the same name: [steve@ando ~]$ cat demo.py def fail(x): f = lambda a: 1/a g = lambda a: f(a-1) return g(x) print fail(1) [steve@ando

Re: Alternative to multi-line lambdas: Assign-anywhere def statements

rce code is not available, then you're equally unable to debug a lambda function and a named function. > even so, which is easier? > > "Oh, the exception occurred in myfunc" > > versus > > "Hmmm, the exception occurred in a lambda, lets see now, that was

Re: Alternative to multi-line lambdas: Assign-anywhere def statements

On Sat, Jan 24, 2015 at 5:58 PM, Ethan Furman wrote: > On 01/24/2015 11:55 AM, Chris Angelico wrote: >> On Sun, Jan 25, 2015 at 5:56 AM, Ethan Furman wrote: >>> If the non-generic is what you're concerned about: >>> >>> # not tested >>> dispatch_table_a = {} >>> dispatch_table_b = {} >>> dispatch

Re: Alternative to multi-line lambdas: Assign-anywhere def statements

m, the exception occurred in a lambda, lets see now, that was called by "f", but f might have called seven different lambdas, which one was it? Oh, I see, f was called by g, and when we call g, this variable is set to foo which only happens when bar was called first, which means that the la

Re: Alternative to multi-line lambdas: Assign-anywhere def statements

Hi Ethan, On Saturday, January 24, 2015 at 9:00:12 PM UTC-5, Ethan Furman wrote: > [...] > __name__ being one of them. One of the reasons lambda > is not encouraged is because its name is always '', which just > ain't helpful when the smelly becomes air borne! ;) Doesn't the traceback tell us e

Re: Alternative to multi-line lambdas: Assign-anywhere def statements

On 01/24/2015 11:55 AM, Chris Angelico wrote: > On Sun, Jan 25, 2015 at 5:56 AM, Ethan Furman wrote: >> If the non-generic is what you're concerned about: >> >> # not tested >> dispatch_table_a = {} >> dispatch_table_b = {} >> dispatch_table_c = {} >> >> class dispatch: >> def __init__(self, dis

Re: Alternative to multi-line lambdas: Assign-anywhere def statements

Hi, On Saturday, January 24, 2015 at 3:36:04 PM UTC-5, Devin Jeanpierre wrote: > [...] > Obviously, nobody will be happy until you can do: > > def call(*a, **kw): return lambda f: f(*a, **kw) > > @call() > def x, y (): > yield 1 > yield 2 > > Actually, maybe not even then. You're proba

Re: Alternative to multi-line lambdas: Assign-anywhere def statements

On 2015-01-24 19:55, Chris Angelico wrote: On Sun, Jan 25, 2015 at 5:56 AM, Ethan Furman wrote: If the non-generic is what you're concerned about: # not tested dispatch_table_a = {} dispatch_table_b = {} dispatch_table_c = {} class dispatch: def __init__(self, dispatch_table): self.disp

Re: Alternative to multi-line lambdas: Assign-anywhere def statements

On Sat, Jan 24, 2015 at 11:55 AM, Chris Angelico wrote: > That's still only able to assign to a key of a dictionary, using the > function name. There's no way to represent fully arbitrary assignment > in Python - normally, you can assign to a name, an attribute, a > subscripted item, etc. (Augment

Re: Alternative to multi-line lambdas: Assign-anywhere def statements

On Sun, Jan 25, 2015 at 5:56 AM, Ethan Furman wrote: > If the non-generic is what you're concerned about: > > # not tested > dispatch_table_a = {} > dispatch_table_b = {} > dispatch_table_c = {} > > class dispatch: > def __init__(self, dispatch_table): > self.dispatch = dispatch_table > de

Re: Alternative to multi-line lambdas: Assign-anywhere def statements

On 01/23/2015 10:28 PM, Chris Angelico wrote: > > cmd = {} > def command(func): > cmd[func.__name__] = func > return func > > @command > def foo(*args): > print("You asked to foo.") > > but this is hardly generic. There's no convenient way to give an > argument to a decorator that sa

Re: Alternative to multi-line lambdas: Assign-anywhere def statements

On 2015-01-24 17:28, Chris Angelico wrote: > but this is hardly generic. There's no convenient way to give an > argument to a decorator that says "please assign this here", short > of using some stupid eval hack... is there? > > (Incidentally, for a non-generic dispatch table, a callable dict > su

Alternative to multi-line lambdas: Assign-anywhere def statements

In some random and rambling discussion about Python, the notion came up that multi-line lambda functions are often sought as a means of populating dictionaries and other such structures. Conceptually, "def foo(...): ..." is broadly equivalent to "foo = FunctionType(...)"; but the only type of assig

Re: Question on lambdas

Ben Finney wrote: > Christoph Becker writes: > >> Ben Finney wrote: >> >>> It's best to remember that ‘lambda’ is syntactic sugar for creating >>> a function; the things it creates are not special in any way, they >>> are normal functions, n

Re: Question on lambdas

Am 09.12.2014 04:09 schrieb memilanuk: so in the first example in my original post: ... lambda: update_label2('A', 100) would this work the same? It looks as though it'd be passing the same two parameters to the same function... lambda: 'A', 100: update_label2() No. Even if it would be all

Re: Question on lambdas

On 12/09/2014 02:15 AM, memilanuk wrote: On 12/08/2014 09:30 PM, Ben Finney wrote: memilanuk writes: ... lambda: update_label2('A', 100) would this work the same? (I don't know what you mean here by “the same”; the same as what?) The above creates a new function, which expects no paramete

Re: Question on lambdas

On 12/08/2014 09:30 PM, Ben Finney wrote: memilanuk writes: ... lambda: update_label2('A', 100) would this work the same? (I don't know what you mean here by “the same”; the same as what?) The above creates a new function, which expects no parameters (because there are no parameters before

Re: Question on lambdas

_value’. The function, when > called, will return the value of ‘some_expr’. > > > Any help would be greatly appreciated. > > Hope that helps. > > It's best to remember that ‘lambda’ is syntactic sugar for creating a > function; the things it creates are not speci

Re: Question on lambdas

On Tue, 09 Dec 2014 02:44:12 +0100, Christoph Becker wrote: > Ben Finney wrote: > >> It's best to remember that ‘lambda’ is syntactic sugar for creating a >> function; the things it creates are not special in any way, they are >> normal functions, not “lambdas”. &g

Re: Question on lambdas

memilanuk writes: > ... > lambda: update_label2('A', 100) > > would this work the same? (I don't know what you mean here by “the same”; the same as what?) The above creates a new function, which expects no parameters (because there are no parameters before its ‘:’). The function, when called,

Re: Question on lambdas

Christoph Becker writes: > Ben Finney wrote: > > > It's best to remember that ‘lambda’ is syntactic sugar for creating > > a function; the things it creates are not special in any way, they > > are normal functions, not “lambdas”. > > Could you please ela

Re: Question on lambdas

On 12/08/2014 03:58 PM, Ben Finney wrote: memilanuk writes: What I'm having trouble finding a concrete answer to is the difference between: lambda: some_expr This creates a new function which expects zero parameters. The function, when called, will return the value of ‘some_expr’. lam

Re: Question on lambdas

On 12/8/2014 8:53 PM, Chris Angelico wrote: On Tue, Dec 9, 2014 at 12:44 PM, Christoph Becker wrote: Ben Finney wrote: It's best to remember that ‘lambda’ is syntactic sugar for creating a function; the things it creates are not special in any way, they are normal functions, not “la

Re: Question on lambdas

On Tue, Dec 9, 2014 at 12:44 PM, Christoph Becker wrote: > Ben Finney wrote: > >> It's best to remember that ‘lambda’ is syntactic sugar for creating a >> function; the things it creates are not special in any way, they are >> normal functions, not “lambdas”. >

Re: Question on lambdas

Ben Finney wrote: > It's best to remember that ‘lambda’ is syntactic sugar for creating a > function; the things it creates are not special in any way, they are > normal functions, not “lambdas”. Could you please elaborate why ‘lambda’ does not create “lambdas”. I'm a Pytho

Re: Question on lambdas

t to remember that ‘lambda’ is syntactic sugar for creating a function; the things it creates are not special in any way, they are normal functions, not “lambdas”. What is different is that the function starts with no name bound to it, and the syntax allows only a single expression as the body of t

Re: Question on lambdas

On Tue, Dec 9, 2014 at 10:58 AM, Ben Finney wrote: >> lambda x=some_value: some_expr > > This creates a new function which expects one parameter named ‘x’, which > parameter has a default value of ‘some_value’. The function, when > called, will return the value of ‘some_expr’. *facepalm* For some

Re: Question on lambdas

On 12/08/2014 03:43 PM, memilanuk wrote: So... I was browsing some questions on reddit, and one of them involved tkinter and lambdas. Managed to help the person out, but in the process ended up with more questions of my own :/ My basic confusion revolves around this: in one instance I see

Re: Question on lambdas

’ is syntactic sugar for creating a function; the things it creates are not special in any way, they are normal functions, not “lambdas”. What is different is that the function starts with no name bound to it, and the syntax allows only a single expression as the body of the function. -- \

Re: Question on lambdas

On Tue, Dec 9, 2014 at 10:43 AM, memilanuk wrote: > What I'm having trouble finding a concrete answer to is the difference > between: > > lambda: some_func > > lambda e: some_func These two are quite simple. (In each case, it's an expression, not a function, for what it's worth.) They're (roughly

Question on lambdas

So... I was browsing some questions on reddit, and one of them involved tkinter and lambdas. Managed to help the person out, but in the process ended up with more questions of my own :/ My basic confusion revolves around this: in one instance I see things like the following: R1

Re: lambdas

Status(object): >> pass >> for key,function,data in definitions: >> setattr(Status,key,property(lambda x: function(data))) >> return Status() >> >> but all my properties now act as if they were invoked with the same data >> even though each one should have

Re: lambdas

key,property(lambda x: function(data))) > return Status() > > but all my properties now act as if they were invoked with the same data even > though each one should have been a new lambda function with it's own > associated data. It seems Python is 'optimizing'?

Re: lambdas

pass > for key,function,data in definitions: > setattr(Status,key,property(lambda x: function(data))) > return Status() > > but all my properties now act as if they were invoked with the same data even > though each one should have been a new lambda function w

Re: lambdas

s() > > but all my properties now act as if they were invoked with the same data even > though each one should have been a new lambda function with it's own > associated data.  It seems Python is 'optimizing'?  all the lambdas to the > same object even though th

lambdas

if they were invoked with the same data even though each one should have been a new lambda function with it's own associated data. It seems Python is 'optimizing'? all the lambdas to the same object even though that's clearly not what I want to do. Anyone have any suggestions

Re: List comprehension + lambdas - strange behaviour

On 5/7/2010 8:31 AM, Neil Cerutti wrote: On 2010-05-07, Terry Reedy wrote: On 5/6/2010 3:34 PM, Artur Siekielski wrote: Hello. I found this strange behaviour of lambdas, closures and list comprehensions: funs = [lambda: x for x in range(5)] [f() for f in funs] [4, 4, 4, 4, 4] You

Re: List comprehension + lambdas - strange behaviour

On 2010-05-07, Terry Reedy wrote: > On 5/6/2010 3:34 PM, Artur Siekielski wrote: >> Hello. >> I found this strange behaviour of lambdas, closures and list >> comprehensions: >> >>>>> funs = [lambda: x for x in range(5)] >>>>> [f() for

Re: List comprehension + lambdas - strange behaviour

On 5/6/2010 3:34 PM, Artur Siekielski wrote: Hello. I found this strange behaviour of lambdas, closures and list comprehensions: funs = [lambda: x for x in range(5)] [f() for f in funs] [4, 4, 4, 4, 4] You succumbed to lambda hypnosis, a common malady ;-). The above will not work in 3.x

Re: List comprehension + lambdas - strange behaviour

On May 6, 9:34 pm, Artur Siekielski wrote: > Hello. > I found this strange behaviour of lambdas, closures and list > comprehensions: > > >>> funs = [lambda: x for x in range(5)] > >>> [f() for f in funs] > > [4, 4, 4, 4, 4] > > Of course I was expec

Re: List comprehension + lambdas - strange behaviour

Artur Siekielski gmail.com> writes: > > Of course I was expecting the list [0, 1, 2, 3, 4] as the result. The > 'x' was bound to the final value of 'range(5)' expression for ALL > defined functions. Can you explain this? Is this only counterintuitive > example or an error in CPython? The former.

Re: List comprehension + lambdas - strange behaviour

On 5/6/2010 12:34 PM Artur Siekielski said... Hello. I found this strange behaviour of lambdas, closures and list comprehensions: funs = [lambda: x for x in range(5)] funs is now a list of lambda functions that return 'x' (whatever it currently is from whereever it's accessib

List comprehension + lambdas - strange behaviour

Hello. I found this strange behaviour of lambdas, closures and list comprehensions: >>> funs = [lambda: x for x in range(5)] >>> [f() for f in funs] [4, 4, 4, 4, 4] Of course I was expecting the list [0, 1, 2, 3, 4] as the result. The 'x' was bound to the final value

Re: Why I hate lambdas (Re: Do any of you recommend Python as afirst programming language?)

"Arnaud Delobelle" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >From what I remember when I looked at the source: stack frames execute code objects, not functions. They don't know what function has spawned them, only what code object they are executing. In fact when one thinks o

Re: Why I hate lambdas (Re: Do any of you recommend Python as a firstprogramming language?)

y one that allows you to write your own versions of them. Today the collections module and other built-in modules gives you some of those data structures, you just need to import them, so using them isn't much a hassle, even if they aren't built in. Aahz>The problem with lambda is that

Re: Why I hate lambdas (Re: Do any of you recommend Python as afirst programming language?)

On Mar 24, 2:01 pm, Steven D'Aprano <[EMAIL PROTECTED] cybersource.com.au> wrote: [...] > > Yes, but what I'm asking is why the code objects have a co_name > attribute. And even if there's a good reason for code objects to have a > name, why do tracebacks use func.func_code.co_name instead of > fun

Re: Why I hate lambdas (Re: Do any of you recommend Python as afirst programming language?)

On Mon, 24 Mar 2008 06:48:10 -0700, Arnaud Delobelle wrote: > On Mar 24, 1:26 pm, Steven D'Aprano <[EMAIL PROTECTED] > cybersource.com.au> wrote: >> On Mon, 24 Mar 2008 04:33:53 -0400, Terry Reedy wrote: >> > The fact that .func_name (which is writeable) is not used at first >> > surprised me unti

Re: Why I hate lambdas (Re: Do any of you recommend Python as afirst programming language?)

On Mar 24, 1:26 pm, Steven D'Aprano <[EMAIL PROTECTED] cybersource.com.au> wrote: > On Mon, 24 Mar 2008 04:33:53 -0400, Terry Reedy wrote: > > The fact that .func_name (which is writeable) is not used at first > > surprised me until I remembered that code objects can potentially be > > used by mult

Re: Why I hate lambdas (Re: Do any of you recommend Python as afirst programming language?)

On Mon, 24 Mar 2008 04:33:53 -0400, Terry Reedy wrote: > The fact that .func_name (which is writeable) is not used at first > surprised me until I remembered that code objects can potentially be > used by multiple function objects and hence are not connected to any one > in particular. How does t

Re: Why I hate lambdas (Re: Do any of you recommend Python as afirst programming language?)

"Steven D'Aprano" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | Unfortunately there's nothing we can do to fix that error. Even though | the function object has an attribute "__name__" (also known as | "func_name") which is set to spam, it isn't used for tracebacks. Instead, | the

Re: Why I hate lambdas (Re: Do any of you recommend Python as a first programming language?)

On Sun, 23 Mar 2008 22:36:35 -0400, Roy Smith wrote: >> > I've also done two things. First, I've created a function object >> > (i.e. a lambda body), and I've also bound the name torture to that >> > function object, in much the same way I did with the list. But, it's >> > different. The functio

Re: Why I hate lambdas (Re: Do any of you recommend Python as a first programming language?)

. I think we're arguing the same thing. When you write def foo(): whatever you create an object which contains the string "foo", retrievable through its __name__ attribute. That's what I meant by "it knows its name" >> What Python give us with lambdas is som

Re: Why I hate lambdas (Re: Do any of you recommend Python as a first programming language?)

factory('lot') both uselessly identify themselves as "f" in tracebacks. The truth is that objects don't know what name they have, because objects don't have names. The relationship is the other way around: names have objects, not vice versa. Some objects (functions, cl

Re: Why I hate lambdas (Re: Do any of you recommend Python as a firstprogramming language?)

types are left anonymous, but how could they get a name when there is no code to give them a name. Yes, fundamentally different categories of types are (sensibly) treated differently with repect to definition and namespace names, but calling that 'disharmony' depends on the listener

Re: Why I hate lambdas (Re: Do any of you recommend Python as a first programming language?)

indow() arguments while I > figure out what the lambda means -- and often the lambda is more > complicated than that. Moreover, because the lambda is unnamed, it's > missing a reading cue for its purpose. I find lambdas invaluable very frequently - often to avoid the reading clut

Re: Why I hate lambdas (Re: Do any of you recommend Python as a first programming language?)

re", not "weapon". Because that IS the function's name. Lists are anonymous. Functions have names (as do a few other things like classes and modules). If I ask a list what its name is, I get: AttributeError: 'list' object has no attribute '__name__'

Re: Why I hate lambdas (Re: Do any of you recommend Python as a first programming language?)

On Sun, 23 Mar 2008 09:24:35 -0700, Aahz wrote: > The problem with lambda is that too often it results in clutter (this is > a strictly made-up example off the top of my head for illustrative > purposes rather than any real code, but I've seen plenty of code similar > at various times): > > g

Re: Why I hate lambdas (Re: Do any of you recommend Python as a first programming language?)

On Mar 23, 12:24 pm, [EMAIL PROTECTED] (Aahz) wrote: > The problem with lambda is that too often it results in clutter (this is > a strictly made-up example off the top of my head for illustrative > purposes rather than any real code, but I've seen plenty of code similar > at various times): > >

Why I hate lambdas (Re: Do any of you recommend Python as a first programming language?)

In article <[EMAIL PROTECTED]>, Jeff Schwab <[EMAIL PROTECTED]> wrote: > >Also, despite reassurances to the contrary, I still get the impression >that there is a strong anti-lambda sentiment among the Python "in" >crowd. Is it just a question of the word "lambda," as opposed to >perceived clea

Re: Autogenerate functions (array of lambdas)

On Sep 6, 3:44 am, Paul Rubin wrote: > Chris Johnson <[EMAIL PROTECTED]> writes: > > a = [lambda: i for i in range(10)] > > print [f() for f in a] > > results in: [9, 9, 9, 9, 9, 9, 9, 9, 9, 9] > > rather than the hoped for: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] > > The usual id

Re: Autogenerate functions (array of lambdas)

Chris Johnson <[EMAIL PROTECTED]> writes: > What I want to do is build an array of lambda functions, like so: > > a = [lambda: i for i in range(10)] Use a factory function for creating the lambdas. The explicit function call will force a new variable binding to be created eac

Re: Autogenerate functions (array of lambdas)

On 9/6/07, Chris Johnson <[EMAIL PROTECTED]> wrote: > > What I want to do is build an array of lambda functions, like so: > > a = [lambda: i for i in range(10)] > > (This is just a demonstrative dummy array. I don't need better ways to > achieve the above functionality.) > > print [f() for f in a]

Re: Autogenerate functions (array of lambdas)

Chris Johnson <[EMAIL PROTECTED]> wrote: > 2) Is there a better or preferred method than the one I've found? > Use function default arguments to keep the current value of i at the point where you define the function. a = [(lambda n=i: n) for i in range(10)] -- http://mail.python.org/mailman/

Re: Autogenerate functions (array of lambdas)

That is, would > this be the behavior you'd want more often than not? As I said, > intuitively, I would think the lambda would treat the iterator > variable as a constant in this context. > 2) Is there a better or preferred method than the one I've found? The problem you encou

Re: Autogenerate functions (array of lambdas)

Chris Johnson <[EMAIL PROTECTED]> writes: > a = [lambda: i for i in range(10)] > print [f() for f in a] > results in: [9, 9, 9, 9, 9, 9, 9, 9, 9, 9] > rather than the hoped for: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] The usual idiom is a = [lambda i=i: i for i in range(10)] That way i is not a free va

Autogenerate functions (array of lambdas)

What I want to do is build an array of lambda functions, like so: a = [lambda: i for i in range(10)] (This is just a demonstrative dummy array. I don't need better ways to achieve the above functionality.) print [f() for f in a] results in: [9, 9, 9, 9, 9, 9, 9, 9, 9, 9] rather than the hoped f

Haskell lambdas in python

Hello python-list, I decided to have some fun and altered a copy of python to use a Haskell-like syntax for declaring lambdas. >>> filter( \ x -> x == 3 or x > 8 , [ 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 , 10 ] ) [3, 9, 10] >>> ( \-> "Hello World!" )() &#x

Re: fun with lambdas

Thanks to all I settled with this: def partial1(f,b): return lambda a:f(a,b) def partial2(f,a): return lambda b:f(a,b) Juan Pablo 2005/10/20, Mike Meyer <[EMAIL PROTECTED]>: > Robert Kern <[EMAIL PROTECTED]> writes: > > Juan Pablo Romero wrote: > >> Hello! > >> > >> given the d

Re: fun with lambdas

Robert Kern <[EMAIL PROTECTED]> writes: > Juan Pablo Romero wrote: >> Hello! >> >> given the definition >> >> def f(a,b): return a+b >> >> With this code: >> >> fs = [ lambda x: f(x,o) for o in [0,1,2]] >> >> or this >> >> fs = [] >> for o in [0,1,2]: >> fs.append( lambda x: f(x,o) ) >>

Re: fun with lambdas

You are asking it to return a list of lambda, not its evaluated value. map(lambda x: f(x,0), [0,1,2]) works. [ f(o) for o in [0,1,2] ] works too. Juan Pablo Romero wrote: > Hello! > > given the definition > > def f(a,b): return a+b > > With this code: > > fs = [ lambda x: f(x,o) for o in [0,1,

Re: fun with lambdas

Juan Pablo Romero wrote: > Hello! > > given the definition > > def f(a,b): return a+b > > With this code: > > fs = [ lambda x: f(x,o) for o in [0,1,2]] > > or this > > fs = [] > for o in [0,1,2]: > fs.append( lambda x: f(x,o) ) > > I'd expect that fs contains partial evaluated functions,

fun with lambdas

Hello! given the definition def f(a,b): return a+b With this code: fs = [ lambda x: f(x,o) for o in [0,1,2]] or this fs = [] for o in [0,1,2]: fs.append( lambda x: f(x,o) ) I'd expect that fs contains partial evaluated functions, i.e. fs[0](0) == 0 fs[1](0) == 1 fs[2](0) == 2 But this

Re: C#3.0 and lambdas

Mike Meyer wrote: > This is a well-known phenomenon, having picked up the name "bikeshed" > something like 40 years ago. Google for "bikeshed color". My favourite "bikeshed" story: A colleague just joined his local Primary School council. On the agenda for his first meeting was that the shelte

Re: C#3.0 and lambdas

Fredrik Lundh wrote: > Reinhold Birkenfeld wrote: > >>> And I think the discussion that followed proved your point perfectly >>> Fredrik. Big discussion over fairly minor things, but no "big picture". >>> Where are the initiatives on the "big stuff" (common documentation >>> format, improved buil

Re: C#3.0 and lambdas

Erik Wilsher wrote: > And I think the discussion that followed proved your point perfectly > Fredrik. Big discussion over fairly minor things, but no "big > picture". Where are the initiatives on the "big stuff" (common > documentation format, improved build system, improved web modules, > rew

Re: C#3.0 and lambdas

> A M Kuchling <[EMAIL PROTECTED]> writes: > The group of committers is a diverse group of people, and not every one of > them uses a relational database; that effort would be better done on the > DB-SIG mailing list, because the people there presumably do all use an > RDBMS. (Now, if you wan

Re: C#3.0 and lambdas

"A.M. Kuchling" <[EMAIL PROTECTED]> writes: > Agreed; python-dev has gotten pretty boring with all the endless discussions > over some minor point. Of course, it's much easier and lower-effort to > propose a syntax or nitpick a small point issue than to tackle a big > complicated issue like static

Re: C#3.0 and lambdas

[amk] > Similar things happen on the catalog SIG: people suggest, or even implement, > an automatic package management system, But bring up the question of whether > it should be called PyPI or Cheeseshop or the Catalog, and *everyone* can make > a suggestion. This is known as the "bike shed effe

Re: C#3.0 and lambdas

On Fri, 23 Sep 2005 15:46:54 +0530, Ganesan Rajagopal <[EMAIL PROTECTED]> wrote: > I agree. I am a lurker in this list and the python-devel list and I've also > noticed that increasingly big discussions happen over fairly minor > things. Python's DB API is still stuck at 2.0 and we can't e

  1   2   >