Label-Value (was: Re: Inheriting the @ sign from Ruby)
daniel at cs.washington.edu
Tue Dec 12 20:35:04 CET 2000
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
def lambdaCB( val ):
lambda = val / constant
but instead I thought that I would have a simple class
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
Clues gratefully accepted,
More information about the Python-list