Changing global variables in tkinter/pmw callback

[Alex Martelli]

"Brian Elmegaard" <be at mek.dtu.dk> wrote in message
news:3ACD5D99.47AED2BE at mek.dtu.dk...
    [snip]
> > ("normal variables", like integers, floats, strings, belong to
> > this category.  if you want a new integer/float/string value,
> > you have to create a new object)
>
> I think it's more the methodology in bindings that confused me, and then
> lambdas also.

You never HAVE to use a lambda: it's supposed to be a convenience,
but, whenever you can use a lambda, you can just as well use a
(named) local function object if that seems clearer to you (and
often it WILL be clearer to most readers).


> > (when you type "s[0] = 10", you ask whatever "s" points to
> > to replace item zero with a new value.  in your case, you ask
> > the list "s" to modify it's first item.  anyone else referring to
> > the same list object will see this change)
>
> And someone are. Could the same be done with the 10 in s=10? If not then
> why?

Numbers of all kinds are among the _immutable_ objects (like tuples
and strings).  This is VERY much what you want, believe me... the
only programming system I ever heard about which let numbers change
value (by accident!-) was a Fortran-II compiler that, when you
called a procedure:
    CALL FOO(3)
would just pass the address of the memory word where it had stored
the number 3.  If FOO internally did (e.g.) N=N+1 on its integer
argument N... then 3 now had a value of four!!!  If some place
after the call you had for example a loop such as
    DO 10, I=1,3
then the loop's body would 'of course' now be executed four times,
for example.

We _don't_ really want this, do we?  Numbers *had better* be
completely immutable objects -- programming becomes a funny
game indeed if the actual values of numbers start changing
from under our feet.

It's unclear, on the other hand, if there NEED to be 'mutable'
objects at all; Haskell, Erlang, and other functional programming
languages, seem to do pretty well by only having immutable data.
Still, that is a BIG conceptual break from the programming
paradigms we're most familiar with (procedural, relational,
object-oriented), which all hinge on having SOME mutable data
(and some re-bindable references, too, in a sense).

So, Python hits a pragmatical compromise: some of the key
low-level objects (numbers, strings, tuples) are immutable;
most kinds of objects at a somewhat higher 'structuring'
level (lists, dictionaries, instances) are mutable.  And
it turns out that just about ALL references in Python are
re-bindable -- items in tuples being the signal exception.


Alex