Beginners' Question -- Assigning variables in a lambda

[Michael Hudson]

digitig at cix.co.uk (Tim Rowe) writes:

> In article <m37lchjgri.fsf at atrus.jesus.cam.ac.uk>, mwh21 at cam.ac.uk 
> (Michael Hudson) wrote:
> 
> Thanks.

Pleasure.

> I'm not really comfortable with either, though. In my version,
> handler will have quite a few keys but two or three actual
> handlers. Your first solution assumes that all keys are handled in
> essentially the same way 

Yes.  My telepathy was obviously having an off day...

> (sorry, I may have wrongly implied that when I said what
> get_number() does). The second solution involves writing a separate
> handler for each key (ok, so does my failed lambda solution, but
> it's more compact!) What I really want to do is assign one of the
> few handlers to each key. All the handlers will assign to a variable
> which I would really like to be in the local scope of the call, but
> global scope would do, but they will derive the variable in
> different ways. For example, the one I've shown interprets the
> parameter as a string representation of a number and converts it to
> a numerical representation; another will force the parameter into
> string form.

Hmm.  Do you really, really need the options to go into variables?
Couldn't you do something like this:

options = { # fill out for defaults
   "bandwidth": 300,
   ...
}

def mksetter(var,val):
    exec """\
def setter(input):
    options[%s] = %s
"""
    return setter

opthandlers = {
   "b" : mksetter("bandwidth","eval(input)"),
   ...
}

Most methods of actually setting variables are likely to be somewhat
fragile.

Anyway, it's getting late and I'm probably not helping, so I'll stop
for now.

> By the way, I don't mind you asserting on user data.
[snip]

Err, yes you do, because if you run python with -O as an command line
option, asserts don't get executed (repeat after me: "assertion
failure's are program bugs").

Cheers,
M.

-- 
  nonono,  while we're making wild  conjectures about the behavior 
  of completely  irrelevant tasks,  we must not  also make serious 
  mistakes, or the data might suddenly become statistically valid.
                                        -- Erik Naggum, comp.lang.lisp