Re: explain this function to me, lambda confusion
On May 8, 6:11 pm, Duncan Booth [EMAIL PROTECTED] wrote: No, no, no, no, no! Geez. Go easy. You have got it entirely wrong here. Your XOR function simply returns a function which gives you the result of xoring the parameters AT THE TIME WHEN YOU ORIGINALLY CREATED IT. I'm guessing that you had already set cream and icecream (otherwise the call to XOR would have thrown an exception) and at leas one was true. Try setting them both False at the beginning: cream = False icecream = False topping = XOR( cream, icecream) cream = True icecream = False print topping() False Ok. I understand this better now. I did say I found the documentation rather terse on this. Using a lambda was a completely pointless exercise here, you could have just returned the result directly: If I try out a new language, I try to exercise those parts of the language that are new to me. Now I saw lambdas, an interesting structure I hadn't seen before. So I tried them out. I get to learn a little at the same time as scripting. That was the point. I only get to optimise my use of a language by trying out various corners of it. def TFF(x,y,z) : return x and not y and not z AddOnly = TFF( options.AddAction, options.ReplaceAction, options.DeleteAction ) DeleteOnly = TFF( options.DeleteAction, options.AddAction, options.ReplaceAction ) ReplaceOnly = TFF( options.ReplaceAction, options.AddAction, options.DeleteAction ) if not (DeleteOnly or AddOnly or ReplaceOnly): print Error: Exactly one of [ --add | --replace | --delete ] allowed. parser.print_help() exit which boils down to: if (options.AddAction + options.ReplaceAction + options.DeleteAction) != 1: print Error: ... Indeed, there are many ways this could be done. Some are more concise, some are more efficient. As I said, I did it the way I did it to try out lambdas. Your way achieves the result, rather elegantly I think, but teaches me nothing about using lambdas. Pardon my tetchiness, but it is a little hard to receive such blunt and inflexible replies to my posts. Both the responses offer lambda free alternatives. That's fine, and given the terse documentation and problems that I had understanding them, I would agree. So what applications are lambdas suited to? I think the parameterised function model is one. What else? -- http://mail.python.org/mailman/listinfo/python-list
Re: explain this function to me, lambda confusion
On May 8, 7:38 am, globalrev [EMAIL PROTECTED] wrote: i have a rough understanding of lambda but so far only have found use for it once(in tkinter when passing lambda as an argument i could circumvent some tricky stuff). what is the point of the following function? def addn(n): return lambda x,inc=n: x+inc if i do addn(5) it returns def addn(n): return lambda x,inc=n: x+inc addn(5) function lambda at 0x01D81830 ok? so what do i write to make it actually do something. and is the inc=n necessary i cant do x+n? Here are some notes I have written for our local wiki on lambdas in python. I hope you will find them illuminating, and I would welcome any suggestions for improving them. I have just cut and pasted from our wiki, so the fancy formatting has been lost. - Python lambdas. The on-line documentation for python lambdas is not very illuminating. Here’s my take and my first simple examples. I would describe a lambda as a parameterised function template. If you dig, the docs call lambdas anonymous functions not bound to a name. There is a bit of resemblance to C macros. Here is a simple lambda that implements an exclusive or: def XOR(x,y) : return lambda : ( ( x ) and not ( y ) ) or ( not ( x ) and ( y ) ) (Because of the resemblance to C macros, I have been cautious and written the lambda with lots of parentheses.) To use this in later code, we define instances of the lambda with specific function arguments. topping = XOR( cream, icecream) sauce = XOR( tomato, BBQ ) We now have two “functions”, topping() and sauce() which we can use later to test flags. cream = True icecream = False print topping() True So in the definition of the XOR lambda, think of x and y as the parameters of the function template, and XOR as the function name placeholder. By putting in specific objects for the parameters (here the boolean variables cream and icecream for example), we produce a specific instance of the lambda, topping() which looks like a function with no arguments. If we use different objects for the parameters (say tomato and BBQ) then we get a different function, sauce. Here is another simple lambda, (template) to set up three new functions AddOnly, DeleteOnly, and ReplaceOnly. #--# Lambda function to check that a flag is only on when the other two are off. #--# def TFF(x,y,z) : return lambda : ( ( x ) and not ( y ) and not ( z ) ) AddOnly = TFF( options.AddAction, options.ReplaceAction, options.DeleteAction ) DeleteOnly = TFF( options.DeleteAction, options.AddAction, options.ReplaceAction ) ReplaceOnly = TFF( options.ReplaceAction, options.AddAction, options.DeleteAction ) if( not (DeleteOnly() or AddOnly() or ReplaceOnly() ) ): print Error: Exactly one of [ --add | --replace | --delete ] allowed. parser.print_help() exit More advanced lambdas. The examples above give function instances that have no arguments, once the parameters of the lambda are chosen. For a function template with arguments and parameters, we add the arguments on the 2nd line. Parameters are in the first line. The Gaussian distribution is exp(-(x-μ)²/ 2σ² ) / √(4 πσ). While we can think of this as a function of three variables, we normally view it as a family of functions of a single variable x, parameterised by μ and σ. Selecting fixed values for μ and σ gives us a single distribution for x. import math def Gaussian( mu, sigma ) : ... return lambda x : math.exp( - (x-mu)**2 / 2 /sigma**2 ) / math.sqrt (2 * math.pi *sigma **2 ) ... and here are some instances: Normal = Gaussian (0, 1) HeightDistrib = (170, 20) which we later use as y = Normal( 0.5 ) 0.35206532676429952 x = 192 HeightDistrib(x) 0.0073381331586869951 I recommend defining the instances of the lambda right after the lambda. If you define it in code far removed from the definition of the lambda, it looks like an assignment, so comment it. -- http://mail.python.org/mailman/listinfo/python-list
Re: unified command line args, environment variables, .conf file settings.
On May 3, 12:16 pm, smitty1e [EMAIL PROTECTED] wrote: Just a fun exercise to unify some of the major input methods for a script into a single dictionary. Here is the output, given a gr.conf file in the same directory with the contents stated below: How about extending this to include other sources of control inputs. I think a reasonable heirarchy is: Interactive Input Command Line Argument Command Line Input File Environment Variables Local Defaults File System Wide Defaults File Installation Defaults File 'Factory' Defaults File In-Code Initialization Defaults -- http://mail.python.org/mailman/listinfo/python-list
Re: explain this function to me, lambda confusion
On May 8, 10:34 am, [EMAIL PROTECTED] wrote: HeightDistrib = (170, 20) That should be HeightDistrib = Gaussian(170, 20) -- http://mail.python.org/mailman/listinfo/python-list
Re: #!/usr/bin/env python vs. #!/usr/bin/python
On May 6, 9:06 pm, Ben Finney [EMAIL PROTECTED] wrote: Wojciech Walczak [EMAIL PROTECTED] writes: 2008/5/6, Banibrata Dutta [EMAIL PROTECTED]: Use /usr/bin/env. If env is not in /usr/bin, put a link to it there. So why not put symlink to Python over there on all machines, if we can put one (or env itself) there ? To avoid linking all the rest of interpreters like perl, ruby, lua and dozens of others. The argument was being made from thousands of scripts. Isn't dozens of symlinks better? It depends on single user vs multi user. We keep multiple versions of packages because some software requires the older versions. Which version do we symlink to? What if we simultaneously require access to two different versions? For example, to keep legacy software going, or to test updated versions while keeping operational versions running. What if we have shared file systems, and we have multiplatform versions? Python for solaris, python for tru64? In a sense, we do have dozens of virtual links, using the modules package to adjust paths on the fly. This is more flexible than having a static symlink in /usr/bin. It allows us to select on a per user, per process, per script basis, the python we want, version, platform etc. With a static symlink, every user/process/job gets the same python, unless you want to flip symlinks around. Also, every 10 years or so, each platform gets replaced, so we are replacing platforms here every few years. And we don't always get the same replacement system. Sure we can go in and touch up all the scripts. But it just seems so much easier and flexible to tell a python/bash/other script to use what you get from the path, and set the paths. Of course, things are different on a single user desktop system, with its own filesystems. If you are sure where python is, and you only have one python, and you don't mind revisiting your scripts and editing them if things change, by all means hard code the python path in. A -- http://mail.python.org/mailman/listinfo/python-list
Re: #!/usr/bin/env python vs. #!/usr/bin/python
At our site we run IRIX, UNICOS, Solaris, Tru64, Linux, cygwin and other unixy OSes. We have python installed in a number of different places: /bin/python /usr/local/bin/python /usr/bin/python /opt/freeware/Python/Python-2.5.1/bin/python ~mataap/platform/python/python-2.5.1 So I cannot assume a single location for python. Nor for any other tool, really. Bash for example. It may indeed be in /usr/bin on many systems, on many others it is not. Note the version specific install points. This allows us to switch over easily to different versions, and keep older versions in case they are needed. We can test new versions before cutting over to them operationally. (This matters for tools that are still changing, like python or bash.) We use the very handy 'modules' package (not python modules, not fortran modules) to adjust our paths and environment variables as needed. Some of the install points are determined by policy, or historical constraints, or hardware limits, or file system layout. Now it is true that it is easy to edit a single script to change the hashbang line. It is not easy to change several hundred scripts, on different machines. It is easy to adjust the environment to point to the right python path, and have all your scripts pick it up automatically. Use /usr/bin/env. If env is not in /usr/bin, put a link to it there. -- http://mail.python.org/mailman/listinfo/python-list
