Label-Value (was: Re: Inheriting the @ sign from Ruby)

[Daniel Wood]

I'm glad this discussion is happening because I've been learning
python and I'm worried that the bloom is coming off of our romance.
Perhaps if I can be more understanding, our relationship can survive
. . .

scarblac at pino.selwerd.nl (Remco Gerlich) writes:

> Integers, longs, complex numbers, strings, functions, tuples, types, floats
> and None are immutable. Most of these are obvious; the number 3 is the
> number 3, why would you change that?!

Here is what I wanted to do.  I have some random parameters, lambda
and beta.  My calculation uses them like so:

plot( lambda, beta )

I'm using pygtk as a widget set.  I have some sliders.  I wanted to
make one of the sliders control lambda and one control beta.  The
control should be scaled by some parameter etc, etc.  Now I could have
a function 

def lambdaCB( val ):
 global lambda
 lambda = val / constant

but instead I thought that I would have a simple class

class ScaleCB:
  def __init__( self, variable, scale ):
    self.variable = variable
    self.scale = scale

  def __call__( self, val )
    self.variable = val / self.scale

(then, I can do lots of parameters with nice simple code instead of
bunches of stupid helper functions.

This obviously didn't work.

I *think* that the "pythonic" sol'n appears to be lambda = [ value ]
or some such.  Clearly, one person's hack is another person's idiom,
but I can't convince myself that this doesn't suck.  It seems like
what I want is a better idiom for a "mutable integer".  I guess it
would be something just like an int but with a set method.

(Excessive detail here: I'm using swig and in fact these variables are
part of swig's cvar interface.  The cvar interface appears to use some
sort of __getattr__ and __setattr__ hooks in a very un-pythonic way.
I'm not sure but I *think* that this is because SWIG is trying to
expose mutable floats, ints, etc.  It basically binds a NAME
(e.g. cvar.myvar) to a C language thing instead of some sort of object
living in cvar.myvar that corresponds to a C language thing.  I
believe that the SWIG notes mentions something about this and
basically SWIG wants you to be able to do "cvar.myvar = 10" and get
the C style effect.  This has the sad effect that you can't take the C
language bindings and use them in any way other than with the official
NAME "cvar.etcetc".)

Clues gratefully accepted,
Daniel.