Re: Lambda returning tuple question, multi-expression

On 3/10/2023 11:15 PM, aapost wrote: On 3/10/23 22:16, Thomas Passin wrote: [...] The additional note in the above is, when taking the def route above, the thing you would have to consider is what scope is the dictionary pids? Do you need to submit it to the lambda and subsequently the functi

Re: Lambda returning tuple question, multi-expression

On 3/10/23 22:16, Thomas Passin wrote: On 3/10/2023 7:07 PM, aapost wrote: which does start to break down readability due to line length, as there isn't really an indention rule set for something uncommonly used. but some renaming makes the pattern clearer pids.update({"messages" :subprocess.

Re: Lambda returning tuple question, multi-expression

On 3/10/2023 10:37 PM, 2qdxy4rzwzuui...@potatochowder.com wrote: On 2023-03-10 at 22:16:05 -0500, Thomas Passin wrote: I'd make the pattern in this example even more understandable and less error-prone: def update_pids(target): cmd = ["tail", "-n", "1", "-f", f"/var/log/{target}"] p

Re: Lambda returning tuple question, multi-expression

On 2023-03-10 at 22:16:05 -0500, Thomas Passin wrote: > I'd make the pattern in this example even more understandable and less > error-prone: > > def update_pids(target): > cmd = ["tail", "-n", "1", "-f", f"/var/log/{target}"] > pids.update({target: subprocess.Popen(cmd)}) if not \ >

Re: Lambda returning tuple question, multi-expression

On 3/10/2023 7:07 PM, aapost wrote: which does start to break down readability due to line length, as there isn't really an indention rule set for something uncommonly used. but some renaming makes the pattern clearer pids.update({"messages" :subprocess.Popen(["cmd1"])}) if not pids["messages

Re: Lambda returning tuple question, multi-expression

On 3/9/23 15:25, Thomas Passin wrote: >>> # this is a code snippet from a Tkinter gui app >>> # in this case lambda is quite convenient >>> self.btn_cancel = Button(self.progress_container, text='Cancel', >>> command=lambda: subprocess.call('taskkill /f /im uberzip.exe', >>> shell=Tr

Re: Lambda returning tuple question, multi-expression

On 3/10/23 18:46, aapost wrote:     main.pids.update({"messages" :subprocess.Popen(["tail", "-n", "1", "-f", "/var/log/messages"])}),     main.pids.update({"syslog" :subprocess.Popen(["tail", "-n", "1", "-f", "/var/log/syslog"])}),     main.pids.update({"kern" :subprocess.Popen([

Re: Lambda returning tuple question, multi-expression

On 09Mar2023 17:55, aapost wrote: On 3/9/23 16:37, Cameron Simpson wrote: Just a note that some code formatters use a trailing comma on the last element to make the commas fold points. Both yapf (my preference) and black let you write a line like (and, indeed, flatten if short enough):    

Re: Lambda returning tuple question, multi-expression

On 3/9/23 16:37, Cameron Simpson wrote: On 09Mar2023 09:06, Alan Gauld wrote: Just a note that some code formatters use a trailing comma on the last element to make the commas fold points. Both yapf (my preference) and black let you write a line like (and, indeed, flatten if short enough):

Re: Lambda returning tuple question, multi-expression

On 3/9/23 04:06, Alan Gauld wrote: Thank you for the feedback, I appreciate the comments. To add a little extra, there is actually a reason I lean toward overuse of .config() for a lot of things even though they could be sent to the constructor (other than that w["attribute"]= doesn't work

Re: Lambda returning tuple question, multi-expression

On Fri, 10 Mar 2023 at 07:43, Thomas Passin wrote: > > On 3/9/2023 3:29 AM, aapost wrote: > > The 'what I am trying to do' is ask a question regarding opinions and > > practices on issuing a sequence of actions within a lambda via a tuple > > (since the common practice approaches against it - main

Re: Lambda returning tuple question, multi-expression

On 09Mar2023 09:06, Alan Gauld wrote: Also layout is all important here. It could get very messy to read if indentation isn't clear. You only have to look at some Javascript code with function definitions as arguments to functions to see how clunky that can be. Just a note that some code forma

Re: Lambda returning tuple question, multi-expression

On 09Mar2023 09:06, Alan Gauld wrote: On 08/03/2023 21:56, aapost wrote: When making a UI there are a lot of binding/trace operations that need to occur that lead to a lot of annoying 1 use function definitions. I don't really see lambda use like below. Lambdas are very common in GUI callback

Re: Lambda returning tuple question, multi-expression

On 3/9/2023 3:29 AM, aapost wrote: The 'what I am trying to do' is ask a question regarding opinions and practices on issuing a sequence of actions within a lambda via a tuple (since the common practice approaches against it - mainly with tkinter - feel more convoluted), and in doing so leaving

Re: Lambda returning tuple question, multi-expression

On 3/9/23 00:13, Thomas Passin wrote: lol.. 'us'.. So.. to give an example from your own code: but_play = Tk.Button(_frame, text='Play', width = BUTTONWIDTH + 1, pady = PADY, command=lambda x=plotmgr:play_macro(x), bg = BUTTON_BG, font = NEWFONT) Can be written as: b = Tk.Button(master=

Re: Lambda returning tuple question, multi-expression

Other than the admittedly subjective viewpoint that using the lambda is confusing, there’s probably nothing wrong with the lambda approach. A couple of alternatives: def e(): for e in (e1,e2,e3): e.config(state="normal") b = tk.Button(master=main, text="Enable",command=e) or b =

Re: Lambda returning tuple question, multi-expression

On 08/03/2023 21:56, aapost wrote: > When making a UI there are a lot of binding/trace operations that need > to occur that lead to a lot of annoying 1 use function definitions. I > don't really see lambda use like below. Lambdas are very common in GUI callbacks but I admit I've never seen tuple

Re: Lambda returning tuple question, multi-expression

On 3/8/2023 11:19 PM, aapost wrote: > In both cases (as per my intent) Well, that's the trouble. You haven't stated your intent, so we're forced to try to reverse engineer it. Below I state what my reverse-engineering effort thinks is your intent. It would be better if you actually said clea

Re: Lambda returning tuple question, multi-expression

On 3/8/23 16:56, aapost wrote: Thomas > Cameron def set_entries_enabled_state(enabled = True): state = 'normal' if enabled else 'disabled' for e in (e1, e2, e3): e.config(state=state) def config_b_and_entries(enabled = True): state = 'normal' if enabled else 'disabled'

Re: Lambda returning tuple question, multi-expression

On 08Mar2023 16:56, aapost wrote: When making a UI there are a lot of binding/trace operations that need to occur that lead to a lot of annoying 1 use function definitions. I don't really see lambda use like below. Giving 2 working lambda examples using a returned tuple to accomplish multipl

Re: Lambda returning tuple question, multi-expression

On 3/8/2023 4:56 PM, aapost wrote: b = tk.Button(master=main, text="Enable") b.config(     command=lambda: (     e1.config(state="normal"),     e2.config(state="normal"),     e3.config(state="normal")     ) ) It's hard to understand what you are trying to do here. I don't rem

RE: lambda issues

Re: "...which takes a callable (the lambda here)" Python lamdas have some severe restrictions. In any place that takes a callable, if a lambda can't serve, just use def to write a function and use the function name. Joseph S. Teledyne Confidential; Commercially Sensitive Business Data

Re: Lambda in parameters

Greetings list, Jane Street is well known for its love of functional programming in general and of OCaml in particular. If you don't know OCaml yet, I highly recommend it. You can think of it as Python with (static) types. Yes i know OCaml when i was exploring haskell and the like. At that tim

Re: Lambda in parameters

Greetings list, Why car and cdr? Well obviously car is content of the address register and cdr is content of data register. Apparently an artefact of a early implementation of lisp. Oh did not know that detail. More twists for sure. Thought lisp did not go lowlevel. Kind Regards, Abdur-Rahma

Re: Lambda in parameters

Greetings, Very clear explanations, rewriting lambdas as a function was the key to understand it. Did not know was a lisp inspiration. My mind still spiralling XD Kind Regards, Abdur-Rahmaan Janhangeer about | blog github

Re: Lambda in parameters

On 18/12/20 7:02 pm, Cameron Simpson wrote: Frankly, I think this is a terrible way to solve this problem, whatever the problem was supposed to be - that is not clear. It demonstrates that a programming language doesn't strictly need data structes -- you can do everything with nothing but funct

Re: Lambda in parameters

On 19Dec2020 07:39, Philippe Meunier wrote: >See also the example reduction >here: https://en.wikipedia.org/wiki/Church_encoding#Church_pairs Thank you for this reference. I've stuck it on my reading list. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list

Re: Lambda in parameters

Abdur-Rahmaan Janhangeer wrote: >The aim of car is to return 1 >but i don't understand how lambda achieves this Cameron Simpson's explanation is very good. See also the example reduction here: https://en.wikipedia.org/wiki/Church_encoding#Church_pairs >This problem was asked by Jane Street. Jan

Re: Lambda in parameters

On 2020-12-18, Barry wrote: >> Implement car and cdr. > Why car and cdr? > > Well obviously car is content of the address register and cdr is content of > data register. > Apparently an artefact of a early implementation of lisp. While car and cdr are lisp operators, the "content of address reg

Re: Lambda in parameters

On Friday, 18 December 2020 at 15:20:59 UTC+1, Abdur-Rahmaan Janhangeer wrote: > The Question: > > # --- > This problem was asked by Jane Street. > > cons(a, b) constructs a pair, and car(pair) and cdr(pair) returns the first > and last element of that pair. For example, car(cons(3, 4)) retur

Re: Lambda in parameters

> On 18 Dec 2020, at 14:23, Abdur-Rahmaan Janhangeer > wrote: > > The Question: > > # --- > This problem was asked by Jane Street. > > cons(a, b) constructs a pair, and car(pair) and cdr(pair) returns the first > and last element of that pair. For example, car(cons(3, 4)) returns 3, and > c

Re: Lambda in parameters

The Question: # --- This problem was asked by Jane Street. cons(a, b) constructs a pair, and car(pair) and cdr(pair) returns the first and last element of that pair. For example, car(cons(3, 4)) returns 3, and cdr(cons(3, 4)) returns 4. Given this implementation of cons: def cons(a, b): def

Re: Lambda in parameters

On 17Dec2020 23:52, Abdur-Rahmaan Janhangeer wrote: >Here is a famous question's solution These look like implementations of Lisp operators, which I've never found easy to remember. So I'll do this from first principles, but looking at the (uncommented) code. This is some gratuitiously tricky

Re: lambda - strange behavior

Kasper Guldmann writes: > I was playing around with lambda functions, but I cannot seem to > fully grasp them. I was running the script below in Python 2.7.5, > and it doesn't do what I want it to. Are lambda functions really > supposed to work that way. How do I make it work as I intend? > > f =

Re: lambda - strange behavior

On Friday, September 20, 2013 8:51:20 PM UTC+5:30, Kasper Guldmann wrote: > I was playing around with lambda functions, but I cannot seem to fully grasp > them. I was running the script below in Python 2.7.5, and it doesn't do what > I want it to. Are lambda functions really supposed to work that w

Re: lambda - strange behavior

On 20/09/2013 16:21, Kasper Guldmann wrote: I was playing around with lambda functions, but I cannot seem to fully grasp them. I was running the script below in Python 2.7.5, and it doesn't do what I want it to. Are lambda functions really supposed to work that way. How do I make it work as I int

Re: lambda - strange behavior

On Sat, Sep 21, 2013 at 1:21 AM, Kasper Guldmann wrote: > f = [] > for n in range(5): > f.append( lambda x: x*n ) You're leaving n as a free variable here. The lambda function will happily look to an enclosing scope, so this doesn't work. But there is a neat trick you can do: f = [] for n in

Re: Lambda function Turing completeness

This is the second part of my posting on the Turing completeness of Python's lambda expressions. This time I am going to define a recursive function as a lambda expression (I use lambda when I am talking about Python's lambda expressions, and λ for the theory – λ calculus.) Now of course it is eas

Re: Lambda function Turing completeness

Musical Notation writes: > Is it possible to write a Turing-complete lambda function (which does > not depend on named functions) in Python? The wording of this question is questionable. Turing completeness is not an attribute of a function, but of a system (for example a programming language or

Re: Lambda function Turing completeness

On Wed, Jul 31, 2013 at 11:55 PM, Steven D'Aprano wrote: > On Wed, 31 Jul 2013 13:53:26 +0700, Musical Notation wrote: > >> Is it possible to write a Turing-complete lambda function (which does >> not depend on named functions) in Python? > > > lambda s: eval(s) eval is a named function. -- http

Re: Lambda function Turing completeness

On Wed, 31 Jul 2013 13:53:26 +0700, Musical Notation wrote: > Is it possible to write a Turing-complete lambda function (which does > not depend on named functions) in Python? lambda s: eval(s) -- Steven -- http://mail.python.org/mailman/listinfo/python-list

Re: Lambda function Turing completeness

On Wed, Jul 31, 2013 at 12:53 AM, Musical Notation wrote: > Is it possible to write a Turing-complete lambda function (which does not > depend on named functions) in Python? Yes, lambda functions are Turing-complete. You can get anonymous recursion by defining the function to take a recursive f

Re: Lambda function Turing completeness

On Wed 31 Jul 2013 08:53:26 AM CEST, Musical Notation wrote: Is it possible to write a Turing-complete lambda function (which does not depend on named functions) in Python? what should a sinlge Turing-complete lambda function be? For me, a programming language can be Turing-complete or a funct

Re: lambda in list comprehension acting funny

On 7/11/2012 11:39 PM, Dennis Lee Bieber wrote: On 12 Jul 2012 03:53:03 GMT, Steven D'Aprano declaimed the following in gmane.comp.python.general: "ALU class"? Googling gives me no clue. Arithmetic/Logic Unit http://en.wikipedia.org/wiki/Arithmetic_logic_unit http://en.wikipedia.o

Re: lambda in list comprehension acting funny

On 15/07/12 10:44:09, Chris Angelico wrote: > On Sun, Jul 15, 2012 at 6:32 PM, Steven D'Aprano > wrote: >> At compile time, Python parses the source code and turns it into byte- >> code. Class and function definitions are executed at run time, the same >> as any other statement. > > Between the p

Re: lambda in list comprehension acting funny

On 7/15/2012 4:32 AM, Steven D'Aprano wrote: On Sun, 15 Jul 2012 10:49:48 +1000, Chris Angelico wrote: On Sun, Jul 15, 2012 at 9:29 AM, Steven D'Aprano wrote: Not necessarily *compile* time, but the distinction is between when the function is defined (which may at compile time, or it may be a

Re: lambda in list comprehension acting funny

On Sun, Jul 15, 2012 at 6:32 PM, Steven D'Aprano wrote: > At compile time, Python parses the source code and turns it into byte- > code. Class and function definitions are executed at run time, the same > as any other statement. Between the parse step and the 'def' execution, a code object is cre

Re: lambda in list comprehension acting funny

On Sun, 15 Jul 2012 10:49:48 +1000, Chris Angelico wrote: > On Sun, Jul 15, 2012 at 9:29 AM, Steven D'Aprano > wrote: >> Not necessarily *compile* time, but the distinction is between when the >> function is defined (which may at compile time, or it may be at run >> time) versus when the function

Re: lambda in list comprehension acting funny

On Sun, Jul 15, 2012 at 9:29 AM, Steven D'Aprano wrote: > Not necessarily *compile* time, but the distinction is between when the > function is defined (which may at compile time, or it may be at run time) > versus when the function is called. I'd treat the def/lambda statement as "compile time"

Re: lambda in list comprehension acting funny

On Sat, Jul 14, 2012 at 4:29 PM, Steven D'Aprano < steve+comp.lang.pyt...@pearwood.info> wrote: > I don't remember whether it is Javascript or PHP that uses dynamic > binding, but whichever it is, it is generally considered to be a bad > idea, at least as the default or only behaviour. > > Bash is

Re: lambda in list comprehension acting funny

On Fri, 13 Jul 2012 12:54:02 -0600, Ian Kelly wrote: > On Fri, Jul 13, 2012 at 11:53 AM, Hans Mulder wrote: >> The function `function` refers to a variable `VERBOSE` that isn't >> local. In some programming langauages, the interpreter would then scan >> the call stack at run-time, looking for a

Re: lambda in list comprehension acting funny

Alister於 2012年7月12日星期四UTC+8下午5時44分15秒寫道： > On Wed, 11 Jul 2012 08:43:11 +0200, Daniel Fetchinson wrote: > > >> funcs = [ lambda x: x**i for i in range( 5 ) ] > >> print funcs[0]( 2 ) > >> print funcs[1]( 2 ) > >> print funcs[2]( 2 ) > >> > >> This gives me > >> > >> 16 16 16 > >> > >> When I was e

Re: lambda in list comprehension acting funny

On Fri, 13 Jul 2012 21:53:10 -0700, rusi wrote: > On Jul 14, 8:43 am, Steven D'Aprano +comp.lang.pyt...@pearwood.info> wrote: >> On Fri, 13 Jul 2012 19:31:24 -0700, rusi wrote: >> > Consider the following >> >> > def foo(x): >> >     i = 100 >> >     if x: >> >         j = [i for i in range(10)]

Re: lambda in list comprehension acting funny

On Jul 14, 8:43 am, Steven D'Aprano wrote: > On Fri, 13 Jul 2012 19:31:24 -0700, rusi wrote: > > Consider the following > > > def foo(x): > >     i = 100 > >     if x: > >         j = [i for i in range(10)] > >         return i > >     else: > >         return i > > A simpler example: > > def foo(

Re: lambda in list comprehension acting funny

On Fri, 13 Jul 2012 19:31:24 -0700, rusi wrote: > Consider the following > > def foo(x): > i = 100 > if x: > j = [i for i in range(10)] > return i > else: > return i A simpler example: def foo(): i = 100 j = [i for i in range(10)] return i In Pyt

Re: lambda in list comprehension acting funny

On Jul 13, 10:53 pm, Hans Mulder wrote: > If you add `global VERBOSE` to `caller`, then there is only one > variable named `VERBOSE` and what `function` does, depends on > the most recent assignment to that variable. > > If you remove your `global VERBOSE`, then there are two > variables by that n

Re: lambda in list comprehension acting funny

On 13/07/12 20:54:02, Ian Kelly wrote: > I've also seen the distinction described as "early" vs. "late" binding > on this list, but I'm not sure how precise that is -- I believe that > terminology more accurately describes whether method and attribute > names are looked up at compile-time or at run

Re: lambda in list comprehension acting funny

On Fri, Jul 13, 2012 at 11:53 AM, Hans Mulder wrote: > The function `function` refers to a variable `VERBOSE` that > isn't local. In some programming langauages, the interpreter > would then scan the call stack at run-time, looking for a scope > where that name is defined. It would find the loca

RE: lambda in list comprehension acting funny

> >> VERBOSE = True > >> > >> def function(arg): > >> if VERBOSE: > >>print("calling function with arg %r" % arg) > >> process(arg) > >> > >> def caller(): > >> VERBOSE = False > >> function(1) > >> > >> - > >> Python semantics: fu

Re: lambda in list comprehension acting funny

On 13/07/12 18:12:40, Prasad, Ramit wrote: >> VERBOSE = True >> >> def function(arg): >> if VERBOSE: >>print("calling function with arg %r" % arg) >> process(arg) >> >> def caller(): >> VERBOSE = False >> function(1) >> >> - >> Pyt

Re: lambda in list comprehension acting funny

On Sat, Jul 14, 2012 at 2:46 AM, rusi wrote: > Ok let me restate: if python were to work that way (without the > global) we could say either > a Python chooses to have dynamic scoping of variables > or > b There is a bug in python's scoping rules Or c, there's a declaration at the top: from __fu

Re: lambda in list comprehension acting funny

On Jul 13, 9:12 pm, "Prasad, Ramit" wrote: > > VERBOSE = True > > > def function(arg): > >     if VERBOSE: > >        print("calling function with arg %r" % arg) > >     process(arg) > > > def caller(): > >     VERBOSE = False > >     function(1) > > > -

RE: lambda in list comprehension acting funny

> VERBOSE = True > > def function(arg): > if VERBOSE: >print("calling function with arg %r" % arg) > process(arg) > > def caller(): > VERBOSE = False > function(1) > > - > Python semantics: function sees VERBOSE False > Haskell

Re: lambda in list comprehension acting funny

To come back to the OPs question. Variables can be assigned. Or they can be bound. [C++ programmers will be familiar with the difference between initialization and assignment] List comprehensions are defined in terms of assignment to the local variable rather than binding. Hence the issue. Below

Re: lambda in list comprehension acting funny

On Jul 13, 11:36 am, Steven D'Aprano wrote: > On Thu, 12 Jul 2012 21:33:40 -0700, rusi wrote: > > On Jul 11, 11:41 am, Daniel Fetchinson > > wrote: > >> funcs = [ lambda x: x**i for i in range( 5 ) ] print funcs[0]( 2 ) > >> print funcs[1]( 2 ) > >> print funcs[2]( 2 ) > > >> This gives me > > >>

Re: lambda in list comprehension acting funny

On Thu, 12 Jul 2012 21:33:40 -0700, rusi wrote: > On Jul 11, 11:41 am, Daniel Fetchinson > wrote: >> funcs = [ lambda x: x**i for i in range( 5 ) ] print funcs[0]( 2 ) >> print funcs[1]( 2 ) >> print funcs[2]( 2 ) >> >> This gives me >> >> 16 >> 16 >> 16 >> >> When I was excepting >> >> 1 >> 2 >>

Re: lambda in list comprehension acting funny

On Jul 11, 11:41 am, Daniel Fetchinson wrote: > funcs = [ lambda x: x**i for i in range( 5 ) ] > print funcs[0]( 2 ) > print funcs[1]( 2 ) > print funcs[2]( 2 ) > > This gives me > > 16 > 16 > 16 > > When I was excepting > > 1 > 2 > 4 > > Does anyone know why? > > Cheers, > Daniel Your expectatio

Re: lambda in list comprehension acting funny

On 12/07/2012 04:59, Steven D'Aprano wrote: On Wed, 11 Jul 2012 08:41:57 +0200, Daniel Fetchinson wrote: funcs = [ lambda x: x**i for i in range( 5 ) ] Here's another solution: from functools import partial funcs = [partial(lambda i, x: x**i, i) for i in range(5)] Notice that the arguments

Re: lambda in list comprehension acting funny

On Wed, Jul 11, 2012 at 9:59 PM, Steven D'Aprano wrote: > On Wed, 11 Jul 2012 08:41:57 +0200, Daniel Fetchinson wrote: > >> funcs = [ lambda x: x**i for i in range( 5 ) ] > > Here's another solution: > > from functools import partial > funcs = [partial(lambda i, x: x**i, i) for i in range(5)] > >

Re: lambda in list comprehension acting funny

On Thu, 12 Jul 2012 09:44:15 +, Alister wrote: > On Wed, 11 Jul 2012 08:43:11 +0200, Daniel Fetchinson wrote: > >>> funcs = [ lambda x: x**i for i in range( 5 ) ] [...] > Having read Steve's explanation in the other thread (which I think has > finally flipped the light switch on lambda for m

Re: lambda in list comprehension acting funny

On Wed, 11 Jul 2012 08:43:11 +0200, Daniel Fetchinson wrote: >> funcs = [ lambda x: x**i for i in range( 5 ) ] >> print funcs[0]( 2 ) >> print funcs[1]( 2 ) >> print funcs[2]( 2 ) >> >> This gives me >> >> 16 16 16 >> >> When I was excepting >> >> 1 >> 2 >> 4 >> >> Does anyone know why? > > And m

Re: lambda in list comprehension acting funny

On 7/11/12 9:21 PM, John Ladasky wrote: Exactly. It's threads like these which remind me why I never use lambda. I would rather give a function an explicit name and adhere to the familiar Python syntax, despite the two extra lines of code. I don't even like the name "lambda". It doesn't tel

Re: lambda in list comprehension acting funny

On 12/07/2012 07:18, Steven D'Aprano wrote: On Wed, 11 Jul 2012 22:04:51 -0700, 8 Dihedral wrote: I have to make sure my functor to keep the state variable values for different objects that call the same functor to behave correctly in order to avoid passing extra parameters in various obj

Re: lambda in list comprehension acting funny

In article , Daniel Fetchinson wrote: > > funcs = [ lambda x: x**i for i in range( 5 ) ] > > print funcs[0]( 2 ) > > print funcs[1]( 2 ) > > print funcs[2]( 2 ) > > > > This gives me > > > > 16 > > 16 > > 16 > > > > When I was excepting > > > > 1 > > 2 > > 4 > > > > Does anyone know why? In Pyt

Re: lambda in list comprehension acting funny

On Wed, 11 Jul 2012 22:04:51 -0700, 8 Dihedral wrote: > I have to make sure my functor to keep the state variable values for > different objects that call the same functor to behave correctly in > order to avoid passing extra parameters in various objects using the > same functor. Yo dawg,

Re: lambda in list comprehension acting funny

On Wed, 11 Jul 2012 13:21:34 -0700 (PDT) John Ladasky wrote: > Exactly. It's threads like these which remind me why I never use lambda. I > would rather give a function an explicit name and adhere to the familiar > Python syntax, despite the two extra lines of code. I don't even like the > nam

Re: lambda in list comprehension acting funny

On Thursday, July 12, 2012 11:51:04 AM UTC+8, Steven D'Aprano wrote: > On Wed, 11 Jul 2012 20:39:45 -0700, 8 Dihedral wrote: > > > I'll contribute my way of python programming: > > > > def powerb(x, b): # > > return x**b > > Here's a shorter version: > > py> pow >

Re: lambda in list comprehension acting funny

On 7/11/2012 11:53 PM, Steven D'Aprano wrote: On Wed, 11 Jul 2012 21:05:30 -0400, Dennis Lee Bieber wrote: {non sequitur: I still recall my archaic C++ class with the OOAD assignment of designing said calculator -- we never had to implement one, just design the basic classes/methods/attributes

Re: lambda in list comprehension acting funny

On Wed, 11 Jul 2012 08:41:57 +0200, Daniel Fetchinson wrote: > funcs = [ lambda x: x**i for i in range( 5 ) ] Here's another solution: from functools import partial funcs = [partial(lambda i, x: x**i, i) for i in range(5)] Notice that the arguments i and x are defined in the opposite order. T

Re: lambda in list comprehension acting funny

On Wed, 11 Jul 2012 20:39:45 -0700, 8 Dihedral wrote: > I'll contribute my way of python programming: > > def powerb(x, b): # > return x**b Here's a shorter version: py> pow > One functor is enough! Nothing we have been discussing in this thread has been a functor, either in the

Re: lambda in list comprehension acting funny

On Wed, 11 Jul 2012 21:05:30 -0400, Dennis Lee Bieber wrote: > {non sequitur: I still recall my archaic C++ class with the OOAD > assignment of designing said calculator -- we never had to implement > one, just design the basic classes/methods/attributes [on 3x5 cards] for > a four-banger. I manag

Re: lambda in list comprehension acting funny

On Thursday, July 12, 2012 12:34:33 AM UTC+8, Ian wrote: > On Wed, Jul 11, 2012 at 4:28 AM, Colin J. Williams wrote: > > I don't understand why you would expect 1, 2, 4. > > Because: > > funcs[0](2) == 2 ** 0 == 1 > funcs[1](2) == 2 ** 1 == 2 > funcs[2](2) == 2 ** 2 == 4 > > > Perh

Re: lambda in list comprehension acting funny

>> You should not be using lambda in this case >> .for x in [2, 3]: >> .funcs = [x**ctr for ctr in range( 5 )] >> .for p in range(5): >> .print x, funcs[p] >> .print > > If you change the requirements, it's always easy to solve problems. But > it is the wrong problem that you ha

Re: lambda in list comprehension acting funny

On Wed, 11 Jul 2012 13:21:34 -0700, John Ladasky wrote: > Exactly. It's threads like these which remind me why I never use > lambda. I would rather give a function an explicit name and adhere to > the familiar Python syntax, despite the two extra lines of code. lambda is familiar Python syntax,

Re: lambda in list comprehension acting funny

On Wed, 11 Jul 2012 11:38:18 -0700, woooee wrote: > You should not be using lambda in this case > .for x in [2, 3]: > .funcs = [x**ctr for ctr in range( 5 )] > .for p in range(5): > .print x, funcs[p] > .print If you change the requirements, it's always easy to solve problem

Re: lambda in list comprehension acting funny

On 11/07/12 20:38:18, woooee wrote: > You should not be using lambda in this case > .for x in [2, 3]: > .funcs = [x**ctr for ctr in range( 5 )] > .for p in range(5): > .print x, funcs[p] > .print The list is called "funcs" because it is meant to contain functions. Your code doe

Re: lambda in list comprehension acting funny

Exactly. It's threads like these which remind me why I never use lambda. I would rather give a function an explicit name and adhere to the familiar Python syntax, despite the two extra lines of code. I don't even like the name "lambda". It doesn't tell you what it is (unless you're John McCa

Re: lambda in list comprehension acting funny

On Wed, Jul 11, 2012 at 4:28 AM, Colin J. Williams wrote: > I don't understand why you would expect 1, 2, 4. Because: funcs[0](2) == 2 ** 0 == 1 funcs[1](2) == 2 ** 1 == 2 funcs[2](2) == 2 ** 2 == 4 > Perhaps parentheses will help the order of evaluation: > > funcs = [(lambda x: x**i) for i in

Re: lambda in list comprehension acting funny

On 11/07/2012 2:41 AM, Daniel Fetchinson wrote: funcs = [ lambda x: x**i for i in range( 5 ) ] print funcs[0]( 2 ) print funcs[1]( 2 ) print funcs[2]( 2 ) This gives me 16 16 16 When I was excepting 1 2 4 Does anyone know why? Cheers, Daniel I don't understand why you would expect 1, 2,

Re: lambda in list comprehension acting funny

>>> funcs = [ lambda x: x**i for i in range( 5 ) ] >>> print funcs[0]( 2 ) >>> >>> This gives me >>> 16 >>> >>> When I was excepting >>> 1 >>> >>> Does anyone know why? > >Just the way Python lambda expressions bind their variable > references. Inner 'i' references the outer scope's 'i' variabl

Re: lambda in list comprehension acting funny

Hi. funcs = [ lambda x: x**i for i in range( 5 ) ] print funcs[0]( 2 ) This gives me 16 When I was excepting 1 Does anyone know why? Just the way Python lambda expressions bind their variable references. Inner 'i' references the outer scope's 'i' variable and not its value 'at the tim

Re: lambda in list comprehension acting funny

> funcs = [ lambda x: x**i for i in range( 5 ) ] > print funcs[0]( 2 ) > print funcs[1]( 2 ) > print funcs[2]( 2 ) > > This gives me > > 16 > 16 > 16 > > When I was excepting > > 1 > 2 > 4 > > Does anyone know why? And more importantly, what's the simplest way to achieve the latter? :) -- Psss,

Re: Lambda question

On 6/6/2011 12:52 PM, Terry Reedy wrote: def group(seq, n): 'Yield from seq successive disjoint slices of length n & the remainder' if n<=0: raise ValueError('group size must be positive') for i in range(0,len(seq), n): yield seq[i:i+n] for inn,out in ( (('',1), []), # no input, no output #(('a

Re: Lambda question

On 6/6/2011 1:29 PM, rusi wrote: On Jun 5, 11:33 pm, Terry Reedy wrote: Let me add something not said much here about designing functions: start with both a clear and succinct definition *and* test cases. (I only started writing tests first a year ago or so.) I am still one year in the futu

Re: Lambda question

Steven D'Aprano wrote: For any non-trivial function, I usually start by writing the documentation (a docstring and doctests) first. How else do you know what the function is supposed to do if you don't have it documented? Yes. In my early years I was no different than any other hacker in terms

Re: Lambda question

On Mon, 06 Jun 2011 12:52:31 -0400, Terry Reedy wrote: > Let me add something not said much here about designing functions: start > with both a clear and succinct definition *and* test cases. (I only > started writing tests first a year ago or so.) For any non-trivial function, I usually start b

Re: Lambda question

On Jun 5, 11:33 pm, Terry Reedy wrote: > On 6/5/2011 5:31 AM, Alain Ketterlin wrote: > > >  writes: > > > f = lambda x, n, acc=[]: f(x[n:], n, acc+[(x[:n])]) if x else acc > > f=lambda ... statements are inferior for practical purposes to the > equivalent def f statements because the resultin

Re: Lambda question

On 6/6/2011 9:42 AM, jyoun...@kc.rr.com wrote: f = lambda x, n, acc=[]: f(x[n:], n, acc+[(x[:n])]) if x else acc Packing tail recursion into one line is bad for both understanding and refactoring. Use better names and a docstring gives def group(seq, n): 'Yield from seq successive disjoin

RE: Lambda question

> f = lambda x, n, acc=[]: f(x[n:], n, acc+[(x[:n])]) if x else acc > Packing tail recursion into one line is bad for both understanding and > refactoring. Use better names and a docstring gives > > def group(seq, n): >'Yield from seq successive disjoint slices of length n plus the > re

Re: Lambda question

On 6/5/2011 5:31 AM, Alain Ketterlin wrote: writes: f = lambda x, n, acc=[]: f(x[n:], n, acc+[(x[:n])]) if x else acc f=lambda ... statements are inferior for practical purposes to the equivalent def f statements because the resulting object is missing a useful name attribute and a docstr

  1   2   3   4   5   >